5 ms·

The "[...]" you deliberately omitted explicitly permits "ignoring the situation completely with unpredictable results".

mpweiher 7y ago
Yeah, for example just reading beyond the array bounds. What current compilers do is about as far away from “ignoring the situation completely” as it is possible to get.
- mehrdadn 7y ago
  Depends how you look at it. They don't ignore it during translation but that's because they work hard to make the program "ignore it completely" (i.e., not spend a single cycle on the possibility) during execution.
  - mpweiher 7y ago
    (a) That's not what the text says. (b) What compilers are doing does not match "ignore at execution", because they also use it to remove completely separate code.
    - mehrdadn 7y ago
      If stripping code whose only relevance is in a UB situation doesn't amount to ignoring the UB situation completely, I don't know what does. It's literally the production of code that is completely ignorant of the UB situation.
      - mpweiher 7y ago
        If that were what it does, I'd agree. It isn't.
        mehrdadn 7y ago
        If you could give an example to actually illustrate what you mean, maybe I'd agree too, but it's a little tough when you don't...
jschwartzi 7y ago
I would interpret that to mean that if memory is uninitialized to a specific value and you're working in a physical rather than virtual address space, then a read from some random pointer to uninitialized data might return an unpredictable value, such as the value of a GPIO register or a word from an RS-232 buffer. There's clearly a defined behavior for that specific platform. And when they're talking about doing something hardware-specific I would take that to be about the MMU on certain platforms. Platforms with an MMU and where the processor is executing code in a virtual address space can generate an access violation if the program code reads data at a virtual address that is not mapped to a specific segment of physical memory. Even when a program runs in a physical address space, the processor may be configured with an address space that is significantly larger than the actual block of memory and registers on the memory bus. And this matters because if you have a 32-bit processor but the upper 3 gigabytes of the address space don't map to a register file or RAM then it's hardware-dependent what happens when you read from those addresses. Some hardware will roll the map over and read from somewhere in the available section of the address space based on the offset, and some hardware will treat that as an error which triggers an access violation. Some hardware will bug out and do something completely unexpected. It's undefined behavior what happens in this case. It has everything to do with how your specific chip, mainframe, or minicomputer is wired. And that's what they're referring to. Undefined behavior does not mean "do whatever you want," it means "do what the hardware would probably do in this situation, or do whatever can be reasonably expected." And that's important here because that means that UB is not carte blanche to violate the programmer's expectations here.
- mehrdadn 7y ago
  As far as the standard's goes, you're interpreting undefined behavior to mean unspecified behavior -- behavior that's well-defined, but whose definition "depends on the implementation" (in this case, your hardware). I mean, I can't stop you if you want to read it that way, but you're literally interpreting it to mean exactly what they did not intend it to mean... that's why they chose separate terms and explicitly told you undefined behavior is allowed to be unpredictable, rather than being required to be implementation-dependent. But let's ignore the standard... who cares what it says... The thing is, what you're asking for inhibits optimizations that many people would very much like to see from their compilers. Like for example if you have an uninitialized function pointer that you only assign to in 1 or 2 locations -- the compiler should be able to just replace the indirect function calls with direct function calls. You're demanding that it doesn't do that, and that it simply call whatever function or non-function that pointer happened to point to. I mean -- you're welcome to ask for that, and maybe your compiler should have a flag to make it behave that way (or maybe it does already? do you use it if so?), but to me and many other people, the compiler should obviously be permitted to see right through that.
taneq 7y ago
What would nasal demons be if not "ignoring the situation completely with unpredictable results"?

Yeah, for example just reading beyond the array bounds. What current compilers do is about as far away from “ignoring the situation completely” as it is possible to get.

mehrdadn 7y ago
Depends how you look at it. They don't ignore it during translation but that's because they work hard to make the program "ignore it completely" (i.e., not spend a single cycle on the possibility) during execution.
- mpweiher 7y ago
  (a) That's not what the text says. (b) What compilers are doing does not match "ignore at execution", because they also use it to remove completely separate code.
  - mehrdadn 7y ago
    If stripping code whose only relevance is in a UB situation doesn't amount to ignoring the UB situation completely, I don't know what does. It's literally the production of code that is completely ignorant of the UB situation.
    - mpweiher 7y ago
      If that were what it does, I'd agree. It isn't.
      - mehrdadn 7y ago
        If you could give an example to actually illustrate what you mean, maybe I'd agree too, but it's a little tough when you don't...

jschwartzi 7y ago

I would interpret that to mean that if memory is uninitialized to a specific value and you're working in a physical rather than virtual address space, then a read from some random pointer to uninitialized data might return an unpredictable value, such as the value of a GPIO register or a word from an RS-232 buffer. There's clearly a defined behavior for that specific platform. And when they're talking about doing something hardware-specific I would take that to be about the MMU on certain platforms. Platforms with an MMU and where the processor is executing code in a virtual address space can generate an access violation if the program code reads data at a virtual address that is not mapped to a specific segment of physical memory. Even when a program runs in a physical address space, the processor may be configured with an address space that is significantly larger than the actual block of memory and registers on the memory bus. And this matters because if you have a 32-bit processor but the upper 3 gigabytes of the address space don't map to a register file or RAM then it's hardware-dependent what happens when you read from those addresses. Some hardware will roll the map over and read from somewhere in the available section of the address space based on the offset, and some hardware will treat that as an error which triggers an access violation. Some hardware will bug out and do something completely unexpected. It's undefined behavior what happens in this case. It has everything to do with how your specific chip, mainframe, or minicomputer is wired. And that's what they're referring to. Undefined behavior does not mean "do whatever you want," it means "do what the hardware would probably do in this situation, or do whatever can be reasonably expected." And that's important here because that means that UB is not carte blanche to violate the programmer's expectations here.

mehrdadn 7y ago
As far as the standard's goes, you're interpreting undefined behavior to mean unspecified behavior -- behavior that's well-defined, but whose definition "depends on the implementation" (in this case, your hardware). I mean, I can't stop you if you want to read it that way, but you're literally interpreting it to mean exactly what they did not intend it to mean... that's why they chose separate terms and explicitly told you undefined behavior is allowed to be unpredictable, rather than being required to be implementation-dependent. But let's ignore the standard... who cares what it says... The thing is, what you're asking for inhibits optimizations that many people would very much like to see from their compilers. Like for example if you have an uninitialized function pointer that you only assign to in 1 or 2 locations -- the compiler should be able to just replace the indirect function calls with direct function calls. You're demanding that it doesn't do that, and that it simply call whatever function or non-function that pointer happened to point to. I mean -- you're welcome to ask for that, and maybe your compiler should have a flag to make it behave that way (or maybe it does already? do you use it if so?), but to me and many other people, the compiler should obviously be permitted to see right through that.

taneq 7y ago

What would nasal demons be if not "ignoring the situation completely with unpredictable results"?