Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



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.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: