6 ms·
Can you really keep all instances of undefined behaviour in C in your head?
by dottedmag 5y ago
Can you really keep all instances of undefined behaviour in C in your head?
- mburee 5y agoWhy would he need to? Just know what is definitely defined and stick with that
- Certhas 5y agoBecause he claimed to keep the entire language in his head, not just a sane subset. You can also keep a sane subset of C++ in your head.
- jb1991 5y agoUndefined behavior means that which is not defined in the standard. The C standard is quite small, and it is very easy to keep all that in your head. There’s no need to have any subset of the language in memory, this is the whole standard.
- adwn 5y ago> Undefined behavior means that which is not defined in the standard. No, you're wrong. "Undefined Behavior" (UB) in the context of C has a very different meaning from the colloquial meaning "not specified". The meaning of UB is explicitly defined in the C standard, and the C standard explicitly lists certain program execution patterns as UB.
- gpderetta 5y agoFrom the sacred texts (emphasis mine): > If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’
- jb1991 5y agoBut do you consider that a "subset" of the language, as parent says?
- deleted 5y ago[deleted]
- pjc50 5y agoThen you can't do arithmetic.
- random_upvoter 5y agoSure. How long do you imagine that list to be?
- qiqitori 5y agoDoes anyone have any examples of undefined behavior in C where it isn't pretty obvious that you'll get undefined behavior?
- erik_seaberg 5y agoa[i] = i++ is undefined, even though a[i] = i and a[j] = i++ each do what they obviously should.
- random_upvoter 5y ago> a[i] = i++ And I would never excrete such a line of code without automatically thinking "hmmm.. does this really do what I think it does?"
- gjulianm 5y agoIf I see a[i] = i++ in a codebase I am immediately removing it as it looks ambiguous, possibly invalid and probably unpredictable.
- adrian_b 5y agoThis is just a very particular case of calling a function with such arguments that the result will depend on the order of evaluation for the arguments. This is an undefined operation in almost all programming languages.
- gnubison 5y agoThis feels like one of those “you’re a fan of X? Name every Y” memes. If someone has some examples that a reasonable person would write, specifically examples that look like the simplest way to do something, then I’d love to hear them. Negative shifts and infinite loops with counters are just not things you normally encounter.
- SubjectToChange 5y ago> This feels like one of those “you’re a fan of X? Name every Y” memes. How can you identify legal C without understanding undefined behavior? Or rather, what is the list of UB that nay professional C developer should be expected to know? > If someone has some examples that a reasonable person would write, specifically examples that look like the simplest way to do something, then I’d love to hear them. Basically all OOP-style C. For instance, the Windows macro #define CONTAINING_RECORD(address, type, field) ((type *)( \ (PCHAR)(address) - \ (ULONG_PTR)(&((type *)0)->field))) The Linux kernel is also an excellent source of these. Also, serialization/deserialization libraries are an excellent source for UB. And huge amounts of code depends on UB by using unsigned char arrays for storage of other types. Furthermore, in practice, C code assumes most of the following: - null pointers are represented as 0, e.g. if(ptr). - pointer provenance does not exist - char and unsigned char are 8-bit bytes - two's-complement arithmetic - page-based memory protection - no types have trap representations - the values of base types, besides floating point, do not have multiple representations. - etc
- gnubison 5y ago> what is the list of UB that nay professional C developer should be expected to know? Off the top of my head, as a non professional C programmer: - can’t read from uninitialized memory - one malloc = one free - signed overflow is undefined - pointers to stack variables can’t outlive the stack variable itself - can’t dereference NULL pointers (Obviously take this with a massive grain of salt, there are almost certainly important ones that I’m forgetting.) > null pointers are represented as 0, e.g. if(ptr). If(ptr) is guaranteed by the standard to work. Memset(ptr, 0, len) is not (and is very broken in other ways as well). > char and unsigned char are 8-bit bytes They’re guaranteed to be one byte, where a byte is at least 8 bits. So unless you’re trying to simulate %256 with an implicit conversion, or relying on unsigned overflow to turn 0xFF into 0x00, then you’ll be fine.