today i learned that if you don't end a C file with a newline, the compiler is free to steal your apes
-
today i learned that if you don't end a C file with a newline, the compiler is free to steal your apes
@wingo UB for compile-time (not run-time) conditions is bonkers (there are more like this).
-
today i learned that if you don't end a C file with a newline, the compiler is free to steal your apes
@wingo Submitting a patch to gcc that auto-enables -Ofast if there’s no newline at the end of the file
-
@whitequark very serious language
@wingo @whitequark
Ritchie probably spins in his grave.These standardization foobars commonly happen when implementors with commercial interests seek to „compromize“ out of being buggy.
Update: @david_chisnall points to this probably just being a misbehaviour of earlier tool chains. See below.
-
today i learned that if you don't end a C file with a newline, the compiler is free to steal your apes
@wingo I remember some C compilers throwing warnings if you did not end the file with a newline, when I worked with TI DSPs more than a decade ago, so I tend to end all my C/H files with a newline since then. Didn't know this is officially a cause for undefined behavior
️ -
@wingo UB for compile-time (not run-time) conditions is bonkers (there are more like this).
-
-
today i learned that if you don't end a C file with a newline, the compiler is free to steal your apes
-
@wingo @whitequark
Ritchie probably spins in his grave.These standardization foobars commonly happen when implementors with commercial interests seek to „compromize“ out of being buggy.
Update: @david_chisnall points to this probably just being a misbehaviour of earlier tool chains. See below.
This has nothing to do with commercial vendors. The original Lex / YACC could not handle token streams that did not terminate with a separator. The very first C compiler would not correctly handle files that did not end with a newline (or, I think, other whitespace) and so the UNIX convention was to always end a file with a newline.
This limitation was picked up by most early C compilers, because they used the same tooling.
Modern compilers tend not to use this kind of tooling (and newer versions can handle this corner case), but the standard didn't want to exclude them.
As a QoI issue, most compilers will simply diagnose this and interpret the file as if it had a newline at the end. Early compilers would, as I recall, simply stop in the middle of parsing (I think. A parser generator I used 20+ years ago had this issue, but I don't remember the details).
-
-
This has nothing to do with commercial vendors. The original Lex / YACC could not handle token streams that did not terminate with a separator. The very first C compiler would not correctly handle files that did not end with a newline (or, I think, other whitespace) and so the UNIX convention was to always end a file with a newline.
This limitation was picked up by most early C compilers, because they used the same tooling.
Modern compilers tend not to use this kind of tooling (and newer versions can handle this corner case), but the standard didn't want to exclude them.
As a QoI issue, most compilers will simply diagnose this and interpret the file as if it had a newline at the end. Early compilers would, as I recall, simply stop in the middle of parsing (I think. A parser generator I used 20+ years ago had this issue, but I don't remember the details).
@david_chisnall @wingo @whitequark Thanks for the insight.
-
@tessarakt @wingo nothing required at all. Undefined behavior means compilers can do as they wish. Fail with diagnostic, fail silently, do what you expect them to do, or something else entirely.
-
R ActivityRelay shared this topic
