• Álvaro González (github)

    I'm not saying it's the case here, but that's how some of my early HTML looked like when you opened it with Windows notepad after years of editing it with multiple programs in different operating systems. I somehow managed to get Unix, Mac and Windows end of line characters, plus some others that technically don't exist.

  • kanade (unregistered)

    What’s uplevel?

    Not much, but don’t call me level.

  • (nodebb)

    I can remember twice where I was "reprimanded" (not really like that) for formatting the code because it showed up as changes in source control.

  • (nodebb) in reply to ObiWayneKenobi

    When I do that, I always indicate it in the comment:

    git commit -m 'reformatted --- NO CODE CHANGES'  foo.c bar.c
  • Jonathan (unregistered) in reply to kanade

    I came here to make the same joke. I don't know what that says about either of us.

  • Eddie (unregistered)

    This may improve test coverage when measure by line

  • (nodebb) in reply to ObiWayneKenobi

    It's annoying when someone makes a small change but also reformats the code, so it's hard to see the substantive change through all the formatting noise. Many diff programs can be told to ignore whitespace changes, but often this only means within and between lines, it doesn't ignore splitting or joining lines.

    Similarly, yesterday I was reviewing a change to a crontab. The programmer had replaced /home/username with ~username in all the paths, so there were changes on every line. There's no built-in way I know of to filter all those out. I could probably extract both versions, then canonicalized the paths in both versions and compared so I could see all the other changes.

  • (nodebb)

    There are a couple less-incompetent explanations:

    1. The code was generated with a template that didn't do line breaks correctly.
    2. Page_PreInit was added by a find/replace that didn't do line breaks correctly.
  • (nodebb) in reply to Álvaro González

    I somehow managed to get Unix, Mac and Windows end of line characters, plus some others that technically don't exist.

    I remember once getting a file to read where all the line endings were CRCRLF.

    But at least you don't have to deal with how MTS handled lines of text any more.

    MTS is/was an alternative (non-IBM, the M of MTS being (the University of) Michigan)) operating system for IBM System/360 and System/370 mainframes. Its native text format was a series of lines rather than a stream of bytes, and each line having length, content, and line number. And the line numbers could be fractional. (Line 1.000 being followed by 1.050 and then 1.340 and then 2.000, etc., with the stored value being "true line number times 1000" to let it easily be stored in an integer format.)

    Interesting to play with, but it must have been "fun" to map that to the "C" model of a stream of bytes. But it does explain why certain things are classed as UB when using FILE * libc calls (notably fseek() outside a sharply restricted set of things(1)) with text files.

    (1) If memory serves, the only non-UB combinations are (0, SEEK_SET), (0, SEEK_CUR) (causes the equivalent of fflush()), (0, SEEK_END), (x, SEEK_SET) where x is a value returned by ftell() for the same FILE *.

    Addendum 2026-09-16 10:52: It might have been CRLFLF instead of CRCRLF. It was 30 years ago, so cut me some slack.

Leave a comment on “Extremely One Line”

Log In or post as a guest

Replying to comment #704364:

Log Out

« Return to Article