Bug 442199

Summary:	DOS line endings are not correctly detected
Product:	[Applications] kdiff3	Reporter:	Dan Albrecht <dan.kdebugs>
Component:	application	Assignee:	michael <reeves.87>
Status:	RESOLVED FIXED
Severity:	normal	CC:	brendon
Priority:	HI
Version:	1.9.3
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:	https://invent.kde.org/sdk/kdiff3/commit/2b86217c32ed515d3a8b308e6194062b4d76be87	Version Fixed In:	1.9.5
Sentry Crash Report:

Description Dan Albrecht 2021-09-09 00:49:00 UTC

SUMMARY
Starting on build 1.9.0 DOS line endings are incorrectly detected as Unix.

STEPS TO REPRODUCE
1. Created a file with CRLF line endings
2. Open the file in kdiff3 with all default settings

OBSERVED RESULT
kdiff3 says the line endings are Unix and shows an extra blank line with every line

EXPECTED RESULT
kdiff3 behaves the same as it did in version 1.8.5, detects the file is actually DOS and doesn't render extra lines

SOFTWARE/OS VERSIONS
Windows: Server 2019, Windows 11

ADDITIONAL INFORMATION
Binaries downloaded from: https://download.kde.org/stable/kdiff3
Changing settings and switching line end style from Autodetect to DOS doesn't make a difference

Comment 1 Brendon Higgins 2021-09-30 20:21:38 UTC

I observe this behaviour also on Linux builds (Debian unstable packages, v1.9.3). Apart from blank lines between every line, I also notice some corruption tends to happen around the second/third/fourth lines (maybe others).

Comment 2 michael 2021-10-25 18:11:05 UTC

Git commit 4d6c22c0cf2cc037f08373e12558ce8e49ac836b by Michael Reeves.
Committed on 25/10/2021 at 18:09.
Pushed by mreeves into branch '1.9'.

Fix DOS end of line detection
FIXE-IN:1.9.4

M  +2    -3    src/SourceData.cpp

https://invent.kde.org/sdk/kdiff3/commit/4d6c22c0cf2cc037f08373e12558ce8e49ac836b

Comment 3 michael 2021-10-25 18:11:47 UTC

Git commit 2b86217c32ed515d3a8b308e6194062b4d76be87 by Michael Reeves.
Committed on 25/10/2021 at 17:43.
Pushed by mreeves into branch 'master'.

Fix DOS end of line detection
FIXE-IN:1.9.4

M  +2    -3    src/SourceData.cpp

https://invent.kde.org/sdk/kdiff3/commit/2b86217c32ed515d3a8b308e6194062b4d76be87

Comment 4 Brendon Higgins 2022-02-25 19:14:30 UTC

I'm tearing my hair out trying to understand why I still see this sometimes. Looks like UTF byte order marks screw up the automatic detection, and the line ending is (incorrectly) assumed to be Unix in that case. If I make two text files with DOS line ending and no BOM, and diff them in kdiff3, it detects those just fine, but if I add BOM to either one, it guesses Unix for that file. So this bug is only partially fixed?

Comment 5 Brendon Higgins 2022-02-25 21:02:24 UTC

Also noticed (just now) kdiff3 fails to detect the line encoding if the file is UTF-16 with DOS lines. Maybe something is wrong with how this "skipBytes" parameter is handled?

Comment 6 michael 2022-10-18 16:32:02 UTC

Full fix in 1.9.5