3 ms·

It does come off as a bit pedantic though. What it comes down to, is that this specification was written by engineers and not mathematicians. These engineers di

It does come off as a bit pedantic though. What it comes down to, is that this specification was written by engineers and not mathematicians. These engineers didn't really care how (in)convenient it was to write proofs about the C semantics, they cared about the language being fast and easy to implement. In practice, any real-world C implementation will allow you to call the main function without overflowing the stack, and that much is obvious, otherwise nobody would use those implementations, so it should be taken as a a given, an axiom. Why doesn't the C standard guarantee a minimum stack size? Because there could be tiny microcontrollers with just 64 bytes of stack on which you can implement some C subset. At the same time, the standard doesn't want to define specifics of stack frame layouts, so, not knowing how much memory is available on your target machine, and not wanting to constrain how a stack frame for some source function is laid out as part of the C standard, it's impossible to compute how deep you can go on your call stack without architectural details, it's implementation dependent. It makes a lot of sense that the standard is the way it is, from an engineering point of view.

abecedarius 11y ago
The problem with this apology for the standard -- that nobody would interpret it so unreasonably -- is that many programmers (like me) wrote programs assuming what seemed like reasonable bounds on how far compiler writers would go in their language lawyering, which a decade or two later got flouted, making our old code start mysteriously breaking, in a hard-to-figure way, only in the latest versions of the compilers, which at the time were notorious for compiler bugs. If you trust the same compiler writers to respect today's common idea of reasonable engineering tradeoffs, well, I hope it works out better for you.
- mpweiher 11y ago
  > The problem with this apology for the standard While I agree with most of what you wrote, it sounds like you are blaming the standard. Seems to me the proper blame is the unreasonableness of the language-lawyering by compiler engineers...which as you point out is a fairly recent phenomenon. I always like to say that my first C compiler was pre-ANSI-C, so by today's language-lawyering all behavior was undefined and therefore the compiler could have done anything at all. Yet for some strange reason the code produced was more predictable than today. http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html
  - to3m 11y ago
    See also: http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasing.html http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasin... and https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWi...

abecedarius 11y ago

The problem with this apology for the standard -- that nobody would interpret it so unreasonably -- is that many programmers (like me) wrote programs assuming what seemed like reasonable bounds on how far compiler writers would go in their language lawyering, which a decade or two later got flouted, making our old code start mysteriously breaking, in a hard-to-figure way, only in the latest versions of the compilers, which at the time were notorious for compiler bugs. If you trust the same compiler writers to respect today's common idea of reasonable engineering tradeoffs, well, I hope it works out better for you.

mpweiher 11y ago
> The problem with this apology for the standard While I agree with most of what you wrote, it sounds like you are blaming the standard. Seems to me the proper blame is the unreasonableness of the language-lawyering by compiler engineers...which as you point out is a fairly recent phenomenon. I always like to say that my first C compiler was pre-ANSI-C, so by today's language-lawyering all behavior was undefined and therefore the compiler could have done anything at all. Yet for some strange reason the code produced was more predictable than today. http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html
- to3m 11y ago
  See also: http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasing.html http://robertoconcerto.blogspot.co.uk/2010/10/strict-aliasin... and https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWi...