4 ms·

There are most certainly guarantees on the generated assembly. The assembly has to enforce the abstract machine. I want to know how it does that. It can change,

There are most certainly guarantees on the generated assembly. The assembly has to enforce the abstract machine. I want to know how it does that. It can change, that's fine, it can be improved, it can be made worse, but the idea that the rust program doesn't run on physical hardware, as explicitly stated in the article, is pure bullshit.

saagarjha 7y ago
> The assembly has to enforce the abstract machine. Yes, but this only really means anything in the absence of undefined behavior. The compiler's job is generate assembly that produces the results that running the code in the abstract machine would, but the issue is that undefined behavior allows the abstract machine to do arbitrary things, so the compiler is free to generate whatever it likes in this case.
- archgoon 7y ago
  Um... this seems to be a stronger case then to ask what the hardware does. If the compiler can generate arbritray code, then the only recourse to understand what the resulting binary actually does is to look at the actual generated assembly. Understanding what the compiler was trying (and yes, this will change based on which compiler version you used) to do would presumably be helpful in that process. Sure, don't design around this behavior, but if you find yourself deploying an executable with undefined behavior, and you need to figure out the scope of the problem; this seems useful. I don't get this hostility to understanding the tools you're using.
  - saagarjha 7y ago
    > the only recourse to understand what the resulting binary actually does is to look at the actual generated assembly Pretty much, yes. > I don't get this hostility to understanding the tools you're using. Don't take me the wrong way: I'm interested in how compilers work, but I accept the concession that I can only really understand their output when my program is free of undefined behavior. It would be nice to have the compiler try its best in the cases where I am violating the rules of the programming language, and often it will do so, but in general I cannot expect this and trying to do so will require making some sort of tradeoff with regards to performance or language power.
ralfjung 7y ago
> The assembly has to enforce the abstract machine. The assembly has to implement the abstract machine only if your program has no UB. The assembly never has to check if memory is "initialized" or not even though that distinction is real on the abstract machine, because if the difference would matter, your program would have UB. To determine if your program has UB, looking at the assembly is useless. The only way is to consider the abstract machine.
- deleted 7y ago
  [deleted]
- archgoon 7y ago
  When you are in UB it's even more interesting to ask what the hardware actually does because the standard will not specify anything.
  - saagarjha 7y ago
    No, because the compiler will not generate code that is consistent in this case.
    - archgoon 7y ago
      So? What do you think I'm arguing for here?
      - saagarjha 7y ago
        There is no standard mapping between "your C code" and "what your computer will do" if your code has undefined behavior. Your compiler will produce some assembly, which you cannot rely on, and that will be "what your hardware does". If that's what you're trying to say I think we agree.
  - ralfjung 7y ago
    The standard will not specify anything, so what the compiler outputs is gibberish. You are literally looking at a sequence of bytes on which no constraints whatsoever are imposed. LLVM could have compiled my UB program do `0xDEADBEEF` (which I assume is not valid x86 but I do not know) and there would be no compiler bug. Looking at `0xDEADBEEF` here is not useful. Trying to interpret the assembly of a UB program is like trying to interpret the noise of a radio when there is no station on the given frequency. It has more to do with fortune telling than anything else. There is no signal in there, or at least not enough of it to be useful.

saagarjha 7y ago

> The assembly has to enforce the abstract machine. Yes, but this only really means anything in the absence of undefined behavior. The compiler's job is generate assembly that produces the results that running the code in the abstract machine would, but the issue is that undefined behavior allows the abstract machine to do arbitrary things, so the compiler is free to generate whatever it likes in this case.

archgoon 7y ago
Um... this seems to be a stronger case then to ask what the hardware does. If the compiler can generate arbritray code, then the only recourse to understand what the resulting binary actually does is to look at the actual generated assembly. Understanding what the compiler was trying (and yes, this will change based on which compiler version you used) to do would presumably be helpful in that process. Sure, don't design around this behavior, but if you find yourself deploying an executable with undefined behavior, and you need to figure out the scope of the problem; this seems useful. I don't get this hostility to understanding the tools you're using.
- saagarjha 7y ago
  > the only recourse to understand what the resulting binary actually does is to look at the actual generated assembly Pretty much, yes. > I don't get this hostility to understanding the tools you're using. Don't take me the wrong way: I'm interested in how compilers work, but I accept the concession that I can only really understand their output when my program is free of undefined behavior. It would be nice to have the compiler try its best in the cases where I am violating the rules of the programming language, and often it will do so, but in general I cannot expect this and trying to do so will require making some sort of tradeoff with regards to performance or language power.

ralfjung 7y ago

> The assembly has to enforce the abstract machine. The assembly has to implement the abstract machine only if your program has no UB. The assembly never has to check if memory is "initialized" or not even though that distinction is real on the abstract machine, because if the difference would matter, your program would have UB. To determine if your program has UB, looking at the assembly is useless. The only way is to consider the abstract machine.

deleted 7y ago
[deleted]
archgoon 7y ago
When you are in UB it's even more interesting to ask what the hardware actually does because the standard will not specify anything.
- saagarjha 7y ago
  No, because the compiler will not generate code that is consistent in this case.
  - archgoon 7y ago
    So? What do you think I'm arguing for here?
    - saagarjha 7y ago
      There is no standard mapping between "your C code" and "what your computer will do" if your code has undefined behavior. Your compiler will produce some assembly, which you cannot rely on, and that will be "what your hardware does". If that's what you're trying to say I think we agree.
- ralfjung 7y ago
  The standard will not specify anything, so what the compiler outputs is gibberish. You are literally looking at a sequence of bytes on which no constraints whatsoever are imposed. LLVM could have compiled my UB program do `0xDEADBEEF` (which I assume is not valid x86 but I do not know) and there would be no compiler bug. Looking at `0xDEADBEEF` here is not useful. Trying to interpret the assembly of a UB program is like trying to interpret the noise of a radio when there is no station on the given frequency. It has more to do with fortune telling than anything else. There is no signal in there, or at least not enough of it to be useful.