3 ms·

All those "pedantic details" let you know how you can write code that a future version of your compiler won't quietly break.

by _kst_ 6y ago

throwaway894345 6y ago
You missed the obvious point: other languages don’t allow you to write code that will break in future versions (obviously provided that the spec doesn’t change in a breaking way, but this is the same for C). The compiler is your lawyer.
- MaxBarraclough 6y ago
  That's a good point. If your Java code compiles with the Eclipse compiler, you can be pretty confident it will compile with the javac compiler. If it doesn't, it's likely to be a compiler bug somewhere. Not so for C. Put another way, C doesn't let you get away with the try it and see approach the way many other languages do.
  - throwaway894345 6y ago
    > Put another way, C doesn't let you get away with the try it and see approach the way many other languages do. Exactly, and I don't see any upside to this "tradeoff". It seems strictly worse, but maybe I'm missing something.
    - MaxBarraclough 6y ago
      In this particular case, part of the complexity is that C explicitly supports 'freestanding' programs, like kernels, where the parameters and return-value of main are inapplicable. More generally it's because the C language standard is steered only partly by the interests of C programmers: 1) the C standard aims to easily support many different platforms and compilers, 2) it aims to remain a compact and stable (slowly changing) language, and 3) it aims for maximal performance. None of those 3 aligns with programmer convenience. Point 1 ties in to the origins of the C standard itself, which was deliberately designed not to nail down every last detail. This was to incorporate different compilers and platforms. e.g. Where Java mandates two's complement, C doesn't. C was carefully designed so that platforms that don't use two's complement, don't have to jump through (many) hoops in order to comply with the standard. Neither should they be tempted to just break the standard for their own convenience/performance. Point 2 means there's tremendous inertia in the C language. There are considerable upsides to the language being slow to change, though. Although mistakes in the language are slower to be fixed, they're also much less likely to make it into the standard in the first place, compared to a fast-moving language like D. It's also a tremendous advantage for compiler engineers - they can spend their time improving their compiler rather than keeping up with the standard. (Related trivia: C++20 will break with tradition and mandate two's complement for signed integer types. I don't think C will do this though.) And finally Point 3. C's weird and wonderful rules on undefined behaviour permit compilers to make strange optimisations and to omit runtime checks, but they require the programmer to have an eagle eye, and undefined behaviour can manifest in peculiar ways that are hard to hunt down. There are endless horror stories of bizarre undefined behaviour. That said, I'm not sure that performance (on modern platforms) is really such a factor in C's quirks. I believe that these days (with modern compilers), C's performance is generally about the same as that of other similar languages that lack broad undefined behaviour, such as Ada. Honourable mention: in at least one instance, undefined behaviour was deliberately introduced into the standard to permit trap-based error-reporting that was convenient on one particular hardware platform. [0] (Previously the relevant action would merely produce an indeterminate value.) I believe this unusual though even for C. [0] http://blog.frama-c.com/index.php?post/2013/03/13/indeterminate-undefined http://blog.frama-c.com/index.php?post/2013/03/13/indetermin... (ctrl-f for Itanium)

All those "pedantic details" let you know how you can write code that a future version of your compiler won't quietly break.

by _kst_ 6y ago

All those "pedantic details" let you know how you can write code that a future version of your compiler won't quietly break.

throwaway894345 6y ago

You missed the obvious point: other languages don’t allow you to write code that will break in future versions (obviously provided that the spec doesn’t change in a breaking way, but this is the same for C). The compiler is your lawyer.

MaxBarraclough 6y ago
That's a good point. If your Java code compiles with the Eclipse compiler, you can be pretty confident it will compile with the javac compiler. If it doesn't, it's likely to be a compiler bug somewhere. Not so for C. Put another way, C doesn't let you get away with the try it and see approach the way many other languages do.
- throwaway894345 6y ago
  > Put another way, C doesn't let you get away with the try it and see approach the way many other languages do. Exactly, and I don't see any upside to this "tradeoff". It seems strictly worse, but maybe I'm missing something.
  - MaxBarraclough 6y ago
    In this particular case, part of the complexity is that C explicitly supports 'freestanding' programs, like kernels, where the parameters and return-value of main are inapplicable. More generally it's because the C language standard is steered only partly by the interests of C programmers: 1) the C standard aims to easily support many different platforms and compilers, 2) it aims to remain a compact and stable (slowly changing) language, and 3) it aims for maximal performance. None of those 3 aligns with programmer convenience. Point 1 ties in to the origins of the C standard itself, which was deliberately designed not to nail down every last detail. This was to incorporate different compilers and platforms. e.g. Where Java mandates two's complement, C doesn't. C was carefully designed so that platforms that don't use two's complement, don't have to jump through (many) hoops in order to comply with the standard. Neither should they be tempted to just break the standard for their own convenience/performance. Point 2 means there's tremendous inertia in the C language. There are considerable upsides to the language being slow to change, though. Although mistakes in the language are slower to be fixed, they're also much less likely to make it into the standard in the first place, compared to a fast-moving language like D. It's also a tremendous advantage for compiler engineers - they can spend their time improving their compiler rather than keeping up with the standard. (Related trivia: C++20 will break with tradition and mandate two's complement for signed integer types. I don't think C will do this though.) And finally Point 3. C's weird and wonderful rules on undefined behaviour permit compilers to make strange optimisations and to omit runtime checks, but they require the programmer to have an eagle eye, and undefined behaviour can manifest in peculiar ways that are hard to hunt down. There are endless horror stories of bizarre undefined behaviour. That said, I'm not sure that performance (on modern platforms) is really such a factor in C's quirks. I believe that these days (with modern compilers), C's performance is generally about the same as that of other similar languages that lack broad undefined behaviour, such as Ada. Honourable mention: in at least one instance, undefined behaviour was deliberately introduced into the standard to permit trap-based error-reporting that was convenient on one particular hardware platform. [0] (Previously the relevant action would merely produce an indeterminate value.) I believe this unusual though even for C. [0] http://blog.frama-c.com/index.php?post/2013/03/13/indeterminate-undefined http://blog.frama-c.com/index.php?post/2013/03/13/indetermin... (ctrl-f for Itanium)