3 ms·

This 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 t

This 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.
  - deleted 5y ago
    [deleted]

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.
- deleted 5y ago
  [deleted]