2 ms·

"unacceptably risky" except I can't think of anything more basic than asking the computer if a > b and it fails at that?

masklinn 4y ago
Why would “basic” and “correct” overlap in any way?
eru 4y ago
UB invades your whole program, not specific lines. However in this case, the culprit wasn't comparison `a > b`, but assignment `a = b`. In general, addition like 'a + b' also isn't safe in C.
- raverbashing 4y ago
  If it's wrong break on compiler time, not on run time The problem is the compiler going implementation defined on the multiplication/assignment then going all language lawyer on the following line and blaming the user > In general, addition like 'a + b' also isn't safe in C. Cool, another reason to retire it
  - josephcsible 4y ago
    > If it's wrong break on compiler time, not on run time The number being multiplied isn't known until runtime, so there's not a good way of doing this.
    - raverbashing 4y ago
      Well, funny that the compiler sees no problem in removing a check (on compile time) of a value that is totally possible to obtain, on runtime
      - UncleEntity 4y ago
        Isn’t the very base issue the program didn’t sanitize the input? Just blindly accepting user input is universally bad methinks.
        raverbashing 4y ago
        We might ask if gcc will feel like keeping the sanitizing checks or it will take them out due to some bout of language lawyering as well...
        eru 4y ago
        I'm not sure what you mean by 'keping the sanitizing check'? A C program is basically a bunch of bytes, and the C standard tells you what those bytes are supposed to mean. A compiler's job is to translate the bytes into whatever target language you fancy, and making sure to preserve the proscribed behaviour. And that's exactly what the compiler did.
- caf 4y ago
  It's not the assignment. It's the multiplication x * 0x1ff. The compiler has done range analysis and knows that at this point, x is non-negative. The programmer has dilgently ensured that values are such that the multiplication can't overflow, therefore the result of it is also non-negative. That means the later check for i being non-negative is trivially true.
lamp987 4y ago
how does it fail at that? it does exactly what the standard advertises. you need to write standard-compliant code.

masklinn 4y ago

Why would “basic” and “correct” overlap in any way?

eru 4y ago

UB invades your whole program, not specific lines. However in this case, the culprit wasn't comparison `a > b`, but assignment `a = b`. In general, addition like 'a + b' also isn't safe in C.

raverbashing 4y ago
If it's wrong break on compiler time, not on run time The problem is the compiler going implementation defined on the multiplication/assignment then going all language lawyer on the following line and blaming the user > In general, addition like 'a + b' also isn't safe in C. Cool, another reason to retire it
- josephcsible 4y ago
  > If it's wrong break on compiler time, not on run time The number being multiplied isn't known until runtime, so there's not a good way of doing this.
  - raverbashing 4y ago
    Well, funny that the compiler sees no problem in removing a check (on compile time) of a value that is totally possible to obtain, on runtime
    - UncleEntity 4y ago
      Isn’t the very base issue the program didn’t sanitize the input? Just blindly accepting user input is universally bad methinks.
      - raverbashing 4y ago
        We might ask if gcc will feel like keeping the sanitizing checks or it will take them out due to some bout of language lawyering as well...
        eru 4y ago
        I'm not sure what you mean by 'keping the sanitizing check'? A C program is basically a bunch of bytes, and the C standard tells you what those bytes are supposed to mean. A compiler's job is to translate the bytes into whatever target language you fancy, and making sure to preserve the proscribed behaviour. And that's exactly what the compiler did.
caf 4y ago
It's not the assignment. It's the multiplication x * 0x1ff. The compiler has done range analysis and knows that at this point, x is non-negative. The programmer has dilgently ensured that values are such that the multiplication can't overflow, therefore the result of it is also non-negative. That means the later check for i being non-negative is trivially true.

lamp987 4y ago

how does it fail at that? it does exactly what the standard advertises. you need to write standard-compliant code.