5 ms·

> I didn’t have to bother about portability This is where it became evident that the class of bug was going to be "assumed the language's machine model gets ou

> I didn’t have to bother about portability This is where it became evident that the class of bug was going to be "assumed the language's machine model gets out of the way if you know the target platform". It's funny how easily we all forget about the nasal demons, but UB != implementation defined.

tom_ 8y ago
But it could by treated equivalently in many cases. The standard, after all, imposes no restrictions. It might not explicitly say that the implementation could behave like that - I don't know what phrase would work - "a documented manner characteristic of the platform", something like that - but by imposing no restriction it leaves the option open. Which is a large part of why people complain.
- gok 8y ago
  That’s not accurate in this example. In C, uint32_t* literally means “a 4 byte-aligned pointer to a 32 bit unsigned int” on every platform. The author wasn’t getting bitten by UB so much as misunderstanding how pointer types work in C.
  - saagarjha 8y ago
    The undefined behavior was that casting an uint32_t * from a char * requires the char * to have pointed to a uint32_t * before, which is not possible for an unaligned pointer.
  - jcranmer 8y ago
    uint32_t literally means "an unsigned integer type with width 32 [bits] and no padding bits" (I'm quoting from the C standard here). It does not imply anything about what the alignment is; a 16-bit processor may well defined the alignment of the 32-bit unsigned integer type to be 2 bytes instead of 4. The incorrect logic that causes the bug is thinking "I know that I can do X in assembly, therefore the naive translation to C should let me do the same thing." The idea that C is portable assembler is very widespread, but it is quite wrong, and it has been wrong for decades. A lot of people complain when they find out that the compiler doesn't work when they to write what is effectively assembler in C syntax, but quite frankly, many more people (including many of those who want it to be portable assembler) would complain if the compiler were to actually treat all C code as portable assembler.
    - tropo 8y ago
      Got an alternative? The trouble here is that lots of programmers want/need a language that is like a portable assembler. It's all well and fine to say that C isn't such a language, but then what language shall we use? Since there isn't an alternative, C needs to be that language.
      - saagarjha 8y ago
        The trouble is that it's really not possible to be a portable assembler. Sure, most processors have instructions to do arithmetic operations, but at some point you're doing things that not all processors support. So either you're going to have to drop the "portable" or "assembler" part at some point.
      - jcranmer 8y ago
        The alternative is to sit down and design a new language for this task, rather than to try to force C to be that language, which is a task that it is successful enough sufficiently often to be touted as the solution and fails at sufficiently often for people to complain that it fails. The problem is that almost no one needs a portable assembler, and even those who want it very often only want it for very small snippets of code. If you want to specify something very exactly that is legal only because of the particulars of your machine, then use assembly. There are certainly a few things that compilers could expose that are poorly exposed in most languages (floating point environment, various flag bit manipulation including checked overflow and add-with-carry, vector instructions, synchronization barriers, underaligned types). But you don't need portable assembly for those things, just better compilers.
        userbinator 8y ago
        rather than to try to force C to be that language Ironic, considering that C was specifically designed for that from the beginning.
        pjmlp 8y ago
        On the context of PDP-11 class hardware. C isn't the first portable systems programming language, it just became ubiquitous thanks to UNIX.
- lmm 8y ago
  It could, but that battle has been lost. C compiler writers care about benchmark performance to the exclusion of all else. People who care about predictable behaviour in code that doesn't follow the exact letter of the language standard have moved on to other languages.

tom_ 8y ago

But it could by treated equivalently in many cases. The standard, after all, imposes no restrictions. It might not explicitly say that the implementation could behave like that - I don't know what phrase would work - "a documented manner characteristic of the platform", something like that - but by imposing no restriction it leaves the option open. Which is a large part of why people complain.

gok 8y ago
That’s not accurate in this example. In C, uint32_t* literally means “a 4 byte-aligned pointer to a 32 bit unsigned int” on every platform. The author wasn’t getting bitten by UB so much as misunderstanding how pointer types work in C.
- saagarjha 8y ago
  The undefined behavior was that casting an uint32_t * from a char * requires the char * to have pointed to a uint32_t * before, which is not possible for an unaligned pointer.
- jcranmer 8y ago
  uint32_t literally means "an unsigned integer type with width 32 [bits] and no padding bits" (I'm quoting from the C standard here). It does not imply anything about what the alignment is; a 16-bit processor may well defined the alignment of the 32-bit unsigned integer type to be 2 bytes instead of 4. The incorrect logic that causes the bug is thinking "I know that I can do X in assembly, therefore the naive translation to C should let me do the same thing." The idea that C is portable assembler is very widespread, but it is quite wrong, and it has been wrong for decades. A lot of people complain when they find out that the compiler doesn't work when they to write what is effectively assembler in C syntax, but quite frankly, many more people (including many of those who want it to be portable assembler) would complain if the compiler were to actually treat all C code as portable assembler.
  - tropo 8y ago
    Got an alternative? The trouble here is that lots of programmers want/need a language that is like a portable assembler. It's all well and fine to say that C isn't such a language, but then what language shall we use? Since there isn't an alternative, C needs to be that language.
    - saagarjha 8y ago
      The trouble is that it's really not possible to be a portable assembler. Sure, most processors have instructions to do arithmetic operations, but at some point you're doing things that not all processors support. So either you're going to have to drop the "portable" or "assembler" part at some point.
    - jcranmer 8y ago
      The alternative is to sit down and design a new language for this task, rather than to try to force C to be that language, which is a task that it is successful enough sufficiently often to be touted as the solution and fails at sufficiently often for people to complain that it fails. The problem is that almost no one needs a portable assembler, and even those who want it very often only want it for very small snippets of code. If you want to specify something very exactly that is legal only because of the particulars of your machine, then use assembly. There are certainly a few things that compilers could expose that are poorly exposed in most languages (floating point environment, various flag bit manipulation including checked overflow and add-with-carry, vector instructions, synchronization barriers, underaligned types). But you don't need portable assembly for those things, just better compilers.
      - userbinator 8y ago
        rather than to try to force C to be that language Ironic, considering that C was specifically designed for that from the beginning.
        pjmlp 8y ago
        On the context of PDP-11 class hardware. C isn't the first portable systems programming language, it just became ubiquitous thanks to UNIX.
lmm 8y ago
It could, but that battle has been lost. C compiler writers care about benchmark performance to the exclusion of all else. People who care about predictable behaviour in code that doesn't follow the exact letter of the language standard have moved on to other languages.