Menu ▾ ▴

#652 GTK3V2MAIN: no line-ending enforcement — main.c's lone CRLF outlier silently normalized to LF by tooling

Next Release
closed
nobody
None
V5.3.1GA
Windows
5
19 hours ago
4 days ago
Allen D Byrne
No

During the doxygen doc-comment triage (PR #21, merged 83204d08, 2026-07-17), app/wlib/gtk3lib/main.c was found to be the only file in the entire GTK3V2MAIN app/ tree using CRLF line endings (every other file uses LF; confirmed via 'file' on all ~65 files touched by that PR, plus spot checks elsewhere). A Python-based batch-editing script used for one of the mechanical fix phases (removing a stray \return tag) opened the file in default text mode, which silently normalized all 194 lines from CRLF to LF as a side effect of that one-line content fix. This went into the merged commit undisclosed in the PR description (which said 'doc-comment-only').

Root cause is a tooling/process gap, not a one-off mistake: nothing in the repo enforces or even declares an intended line-ending convention.

  • AStyle (app/lib/astylerc) has no --lineend option set, so it explicitly preserves whatever line-ending style is already in each input file (verified empirically with the CI-pinned astyle 3.6.13 against a CRLF test file — astyle left it as CRLF, reporting 'Unchanged'). So the astyle-check CI gate would not have caught, and would not have prevented, either the original CRLF outlier or a future accidental normalization in the other direction.
  • Any other tool/script that opens files in a text mode that doesn't explicitly preserve line endings (as this Python script did) can silently rewrite an entire file's EOL style while making an otherwise-tiny content change, burying a large mechanical diff inside what looks like a small fix.

In this specific instance the maintainer reviewed and decided to leave the LF normalization as-is (net effect is arguably positive: main.c now matches the other ~500 files in the tree). But the underlying gap remains: there is no enforced or declared line-ending policy, so this can recur silently in either direction.

Discussion

  • strobelight

    strobelight - 3 days ago

    git? this is a mercurial repo.

     

  • Allen D Byrne

    Allen D Byrne - 3 days ago

    Yeah I know! But the important item is the astyle change: (app/lib/astylerc)

     

  • Allen D Byrne

    Allen D Byrne - 2 days ago
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,10 +1,7 @@
 During the doxygen doc-comment triage (PR #21, merged 83204d08, 2026-07-17), app/wlib/gtk3lib/main.c was found to be the only file in the entire GTK3V2MAIN app/ tree using CRLF line endings (every other file uses LF; confirmed via 'file' on all ~65 files touched by that PR, plus spot checks elsewhere). A Python-based batch-editing script used for one of the mechanical fix phases (removing a stray \return tag) opened the file in default text mode, which silently normalized all 194 lines from CRLF to LF as a side effect of that one-line content fix. This went into the merged commit undisclosed in the PR description (which said 'doc-comment-only').

 Root cause is a tooling/process gap, not a one-off mistake: nothing in the repo enforces or even declares an intended line-ending convention.
-- No .gitattributes file exists at the repo root.

 - AStyle (app/lib/astylerc) has no --lineend option set, so it explicitly preserves whatever line-ending style is already in each input file (verified empirically with the CI-pinned astyle 3.6.13 against a CRLF test file — astyle left it as CRLF, reporting 'Unchanged'). So the astyle-check CI gate would not have caught, and would not have prevented, either the original CRLF outlier or a future accidental normalization in the other direction.
 - Any other tool/script that opens files in a text mode that doesn't explicitly preserve line endings (as this Python script did) can silently rewrite an entire file's EOL style while making an otherwise-tiny content change, burying a large mechanical diff inside what looks like a small fix.

 In this specific instance the maintainer reviewed and decided to leave the LF normalization as-is (net effect is arguably positive: main.c now matches the other ~500 files in the tree). But the underlying gap remains: there is no enforced or declared line-ending policy, so this can recur silently in either direction.
-
-Suggested fix: add a .gitattributes declaring the intended convention (e.g. '* text=auto eol=lf' given LF is the de facto standard everywhere else in the tree), so git itself normalizes on checkin/checkout and flags/fixes stray CRLF files consistently, independent of which tool or script happens to touch a file next.
    • status: --> open
    • XTrackCAD Version: --> V5.3.1GA
    • OS Level: -->
    • Operating System: --> Windows
    • Priority: --> 5
    • Milestone: --> Next Release
     

  • Allen D Byrne

    Allen D Byrne - 2 days ago

    I removed the refs to git, the actual change set should not include git files.
    Also actually created the branch showing no git files.

     

    Last edit: Allen D Byrne 2 days ago

Anonymous
Anonymous

Add attachments
Cancel





MongoDB Logo MongoDB