4 ms·

The spirit of the article and your comment seems to underrate the efforts required to come up with something like the standard for a C compiler. It's not a "pe

by scoutt 5y ago

The spirit of the article and your comment seems to underrate the efforts required to come up with something like the standard for a C compiler. It's not a "perverse shield". In C, "optimize for correctness" is the programmer's job. I don't want to sound dismissive, and I don't pretend you to write a compiler, but please tell me how would you word a global standard for generating compilers that can compile for hundreds of architectures, with the main focus of being portable and generating the most performant code (no runtime checks). You might come up with a standard similar to something like Rust (which does not have an standard yet, and has only a single compiler "brand"). But Rust is super-difficult to understand and part of its safeness depends on runtime checks, including runtime checks on ownership like RefCell, impacting on performance. The same goes for Ada and other runtime-checked languages. Or you'll end up with something like a standard for C, in which you assume the programmer can be somewhat trusted allowing the compiler to generate faster code, and having to deal with little caveats that depends on certain architectures.

mjburgess 5y ago
I am sympathetic with the view that compiler writers are trapped by the architectures they have to support. However, I think there's just a philosophical difference here about what compilers are for: are they responsible for emitting correct programs; or are they for literal transpiling? Regardless of the history which has led to the latter outcome for C, I have to agree with the author that I think K&R's original vision wasn't quite so accommodating. Perhaps ignorantly, I just have to imagine there is something a little better than the present attitude. Could there not be a --hault-on-all-undef with a serious attempt to realise that in as many respects as possible?
- scoutt 5y ago
  > emitting correct programs; or are they for literal transpiling? I guess the former. I am sure you are familiar with the "garbage-in, garbage-out" concept. The rules are set in the standard. If you feed the compiler with code outside the rules of the standard (even if syntactically correct), you cannot expect correct programs 100% of the time. The standard (somehow) guarantees that code that follows the rules should translate into correct programs. Some of the rules dictate the compiler to "do this", other dictate "do something but specify what you are doing" and "do whatever you want, including exploding, I don't care". Many of these rules are this way for the sake of generating optimized code. These are the rules. Are these rules too many to remember? Unfortunately yes, they are. > I just have to imagine there is something a little better than the present attitude. My crazy hope is that someday runtime checks will be done at silicon level. That is, compiler emits instructions declaring "this is an array of this dimension", and every time this array is accessed with the proper instructions (and the CPU is somehow aware of this), it triggers an interrupt when accessed out of bounds, for example. > Could there not be a --hault-on-all-undef with a serious attempt to realise that in as many respects as possible? It might not be possible for every piece of code. It will have to stop the compilation (or execution with runtime checks) at every int increment/operation. So I think that if rules cannot be generally applicable then they shouldn't be applicable at all.

by scoutt 5y ago

mjburgess 5y ago

I am sympathetic with the view that compiler writers are trapped by the architectures they have to support. However, I think there's just a philosophical difference here about what compilers are for: are they responsible for emitting correct programs; or are they for literal transpiling? Regardless of the history which has led to the latter outcome for C, I have to agree with the author that I think K&R's original vision wasn't quite so accommodating. Perhaps ignorantly, I just have to imagine there is something a little better than the present attitude. Could there not be a --hault-on-all-undef with a serious attempt to realise that in as many respects as possible?

scoutt 5y ago
> emitting correct programs; or are they for literal transpiling? I guess the former. I am sure you are familiar with the "garbage-in, garbage-out" concept. The rules are set in the standard. If you feed the compiler with code outside the rules of the standard (even if syntactically correct), you cannot expect correct programs 100% of the time. The standard (somehow) guarantees that code that follows the rules should translate into correct programs. Some of the rules dictate the compiler to "do this", other dictate "do something but specify what you are doing" and "do whatever you want, including exploding, I don't care". Many of these rules are this way for the sake of generating optimized code. These are the rules. Are these rules too many to remember? Unfortunately yes, they are. > I just have to imagine there is something a little better than the present attitude. My crazy hope is that someday runtime checks will be done at silicon level. That is, compiler emits instructions declaring "this is an array of this dimension", and every time this array is accessed with the proper instructions (and the CPU is somehow aware of this), it triggers an interrupt when accessed out of bounds, for example. > Could there not be a --hault-on-all-undef with a serious attempt to realise that in as many respects as possible? It might not be possible for every piece of code. It will have to stop the compilation (or execution with runtime checks) at every int increment/operation. So I think that if rules cannot be generally applicable then they shouldn't be applicable at all.