3 ms·

In my experience most people don't get exposed to underflows and overflows when learning programming. It's not until they hit a bug that they actually find out

In my experience most people don't get exposed to underflows and overflows when learning programming. It's not until they hit a bug that they actually find out overflows and underflows exist. Then, in my experience they don't go read the spec. They ask a co-worker or google it. They may or may not end up with the correct answer vs an answer that works at the moment. I've used C since the mid 80s and C++ since the late 90s. Overflow for me always worked as a normal 2's compliment overflow on every project from 1985 to 2011 so I had no reason to question that it might be undefined.... until it was. Even more interesting is when asking a mailing list of 200+ C++ experts, the answers for how to actually detect overflow where all over the place. Meaning no one really knew for sure the spec correct way to check even though they were all C++ guys with +15 years experience There's all kinds of details to languages that are buried in a spec but are not something that comes up "in your first few hours with the language".

userbinator 11y ago
Relevant article expressing the same sentiment: http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html
phicoh 11y ago
The problem with the C standard is that most programmers treat C as portable assembler whereas from the beginning the group that wrote the standard tried to make it a proper, abstract high-level language. So we got an enormous disconnect between what programmers expect and what the language really offers. For a long time, compilers would side with the programmers making sure that optimisations would not break common idiom. A number of years gcc left that path. So now, for system code, certainly if the code has to be secure, it is better to avoid gcc. The C standard is in some areas extremely complex, and it doesn't make sense to expect all programmers to completely understand what is essentially a broken standard.
- eru 11y ago
  Perhaps we should even leave C as a language for system code. (System code has to be correct and secure first. Optimization for speed comes second, and is only needed for a few small, very hot code paths.)

userbinator 11y ago

Relevant article expressing the same sentiment: http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html

phicoh 11y ago

The problem with the C standard is that most programmers treat C as portable assembler whereas from the beginning the group that wrote the standard tried to make it a proper, abstract high-level language. So we got an enormous disconnect between what programmers expect and what the language really offers. For a long time, compilers would side with the programmers making sure that optimisations would not break common idiom. A number of years gcc left that path. So now, for system code, certainly if the code has to be secure, it is better to avoid gcc. The C standard is in some areas extremely complex, and it doesn't make sense to expect all programmers to completely understand what is essentially a broken standard.

eru 11y ago
Perhaps we should even leave C as a language for system code. (System code has to be correct and secure first. Optimization for speed comes second, and is only needed for a few small, very hot code paths.)