And compiler developers in the real world are also increasingly nervous at this state of affairs. The subset of C that works in practice is unspecified. There are plenty of optimizations that compiler developers would like to do, but they don't because they're worried about breaking some code somewhere that relies on undefined behavior (like the code you're talking about). At the same time, performance competition pushes compilers to exploit undefined behavior more and more heavily. There is (IMHO, well-founded) worry across the board that this situation is not sustainable. Experience with this problem motivated the design of languages like Swift, which try to clamp down on UB drastically—which also has the happy side effect of making articles like this one inapplicable.
Undefined behavior has already had practical consequences, such as security-sensitive VM escapes: https://bugs.chromium.org/p/nativeclient/issues/detail?id=24...
However, "it's implementation specific and it's most probably this, or that if you use such and such a compiler flag" is different from "I don't know".
As a rule of thumb, don't assume things about C's abstractions, read the standard instead, or ask friendly humans who do if they check out.
From ISO/IEC 9899:2011:
3.6
byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
environment
NOTE 1 It is possible to express the address of each
individual byte of an object uniquely.
NOTE 2 A byte is composed of a contiguous sequence of bits,
the number of which is implementation-defined. The least
significant bit is called the low-order bit; the most
significant bit is called the high-order bit.
It is worth remembering that POSIX (and Windows probably too) mandate 8bit chars so there is no point being defensive about it on these particular platforms. And I kid you not, I have seen people who are. Because "ISO C99 this and that".
Casey Muratori, who's a better C programmer than me, is of the opinion that you should check your compiler's behavior rather than read standards.
(Not that you should take his word as gospel, I don't fully agree myself, but it's worth considering.)
It's much better to avoid undefined behavior entirely. The problem with this idea is that it's hard to learn and remember all the different kinds of undefined behavior.
>> Casey Muratori, who's a better C programmer than me, is of the opinion that you should check your compiler's behavior rather than read standards.
In Casey Muratori's case, he's the type of person who cares to understand what the compiler is actually generating under the hood. He doesn't exactly trust the compiler to always do the right thing.
There was an episode of Handmade Hero where he caught an optimization #fail of the compiler and tried to figure out what was going on (live). https://twitter.com/cmuratori/status/596775025023287297
Casey Muratori also has been developing in Visual Studio for a very long time. Visual Studio has a long, tortuous, history of being non-stanards compliant and buggy. And Microsoft until very recently, never cared to fix anything. (And it still doesn't conform to C99, let alone C11.)
Whatever C related updates you might see, are the ones required by the ANSI C++ for C compatibility.
For C99 and C11 support there is the clang frontend to C2, the Visual C++ backend, currently taking an LLVM role at Microsoft, being shared between clang, VC++ and .NET Native.
Given: 1) There are various optimizations that may kick in or not depending on UB. 2) The cleverness of the optimizer may and does(!) change between versions. 3) There's no "-warn-on-optimizer-changes" flag for any compiler.
Do you think it's realistic to compare compiler output whenever you upgrade your compiler? Do you think it's realistic for 1M SLoC projects? If not, do you take a statistical approach with random sampling? If so, I'd be very interested. If not... what exactly are you sure of and how?
Do both.
Disassemble your compiler's output to see what horrors the optimizer inflicted on your code to "break" it. Read the standard to understand why it thought it was an okay optimization to do in your case, to avoid running afoul of the same mistake again. Ask what other optimizations are enabled by this undefined behavior, the better to spot them when the code your coworker's former boss's roomate, who interned for a month or two, invokes undefined behavior.
Repeat.
(To be fair, I haven't read the standards cover to cover - perhaps I should, I'm still occasionally learning about new and exciting forms of UB...)
There is one thing I have noticed in gcc and clang which is done against the standards: The sign of bit sized int in a struct.
eg: In a struct with member 'int a:8', The standard says that 'a' can be signed or unsigned (based on the machines default of the sign of char). But In gcc and clang, this is signed always regardless of the machine.
Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not?
It's permitted. The same way as a char can be signed or unsigned: Implementation defined. But in this case, it's always signed regardless of the architecture (against how a char is handled).
From c99 draft (n1570), J.3.9 (Implementation-defined behavior): Whether a ‘‘plain’’ int bit-field is treated as a signed int bit-field or as an unsigned int bit-field (6.7.2, 6.7.2.1).
But say, another compiler (ARM compiler) treats this differently [0]: Untill version 5 of the compiler, such an int was unsigned by default. Later versions defaulted to signed (as do gcc/clang).
[0] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
It is, but not required to be an octect. Quoting from the standard (n1570, 3.6):
byte ==== addressable unit of data storage large enough to hold any member of the basic character set of the execution environment
Later in a comment (page 44 in pdf, note 49): A byte contains CHAR_BIT bits
It does, via bit-fields.
To be honest, I hope compilers don't do such things. I would vastly prefer to see it run Tower of Hanoi simulation in Emacs at this point.
But evading bound-checking of 8bit math done in 32bit registers is totally reasonable (by the standard of usual UB optimizations), thanks.
(edit: i misread, it's always 1) To be pedantic, a size of char is defined by CHAR_BIT in limits.h. As well as all of the min and max values and lengths in bits for integers.
To add to the discussion, many high level languages don't have a hard min and max values (haskell, that is popular in these woods, i see has minBound/maxBound).
From the "So you think you know C?" test i answered... probably correct for the "standard" x86 implementation, while knowing that they are implementation specific (for 4 i'm not sure). The authors "Don't know" is his own, i would have answered the questions as "It depends", but that was not offered.
In the end i agree with the general notion here, that this is ugly C.
PS Integer wrapping is undefined as well, so "good" C code should work around it. (i miss this from assembly)
To be even more pedantic: it's the number of bits in a char that is defined by CHAR_BIT. However, sizeof returns the number of chars needed to store a type, where sizeof(char) is defined to be 1.
Nevermind me.
Signed integer overflow is undefined. Unsigned integer overflow is defined.
Ever since, reading introductions to C that say things like "a char is usually one byte in size" make me cringe. I never bothered to check, though, what C89/C90 had to say on this.
Back when I used to code C professionally on early 2000's, these type of issues were quite common.
Specially since regardless of what one reads on HN, or hears at most conferences, most of those companies, which tend to see IT as a cost center, usually don't employ any processes regarding code reviews, static analysis or unit tests.
Which in languages like C this means an heavy price when things blow up, or the way things are going with IoT.
So given the increase in CVE entries, this still matters a lot.
CppCon 2015: Herb Sutter "Writing Good C++14... By Default"
https://www.youtube.com/watch?v=hEx5DNLWGg
When he asks the audience how many use such type of tools regularity, he gets around 1% as result.
I see this with the other languages as well, such practices are still seen as extra costs, shuffled to the end of the projects.
Unless the customer has software development as core business, there the attitude is quite different.
Very sad.
Or I could be way off base - I've never attended CppCon. And I do love me some ASAN when I need it ;)
So... could you explain what you're insinuating so I could respond to that instead of just guessing?
[1] Not sure about CppCon, but all "technical" conferences I've personally been to did have a lot of late-night drinking, but that was secondary to the technical stuff.
The list of qualifiers and disclaimers in that sentence made me dizzier than taking that quiz on dark corners of C.
Less is more.
However, I think that your original sentence is fine too. GP is being a bit pedantic.
What I'm saying is that knowing these minute details doesn't make one a proficient developer with the language, nor does getting every one of this list wrong a bad developer. Sure, with 10 years of experience most people would run into one or two on the list and know about it; still doesn't make the premise that not knowing or caring about trivia competitions makes one not 'know' the language.
The moment one needs to work with more than one compiler, including different versions of the same compiler, one needs to become a language lawyer to keep some sanity.
[1] I know the source of error wasn't related to these exact questions.
https://gcc.gnu.org/onlinedocs/gnat_rm/Value_005fSize-and-Ob...
On second thought, who cares about reading its for squares and nerds. I would rather spend 2 hours Google searching what is an octet and finding out how enums are represented... :p
LaTeX (and probably TeX alone, but I never use it without LaTeX) supports something similar, but AFAICT only in appropriate contexts (matching pairs of `` and '' are converted to the appropriate quote, as are ` and ', but they don't seem to affect "typewriter text", so the smart quotes stay out of my code snippets). Or maybe I just haven't noticed LaTeX munging all over my document.
One might argue, though, whether it's really a good thing to be resilient against crappy WordPress blogs, since it encourages running copy-pasted code from the web. But I guess that would happen anyway, regardless of language designer intentions and a little frustration with copy-pasting won't cause people to actually read the code they're running.
Also, why would anyone write ' ' * 13? For most of these questions, if your first instinct is "that doesn't look like good C code", your answer is better than the "right" answer.