4 ms·

I'd agree with "undefined behavior != the compiler should do whatever it wants" - but I feel I must admit that the standard lets it, that many compiler authors

I'd agree with "undefined behavior != the compiler should do whatever it wants" - but I feel I must admit that the standard lets it, that many compiler authors apparently disagree with me, and that even those who do are sympathetic to my point of view or agree with me may have a point when they say that reason about programmer intention is a difficult bag of worms - and that preserving such, while maintaining "critical" optimizations, may not be as easy as it sounds. There's always -O0.

mpweiher 10y ago
There is a difference between "complies with the standard" and "is bug free". There were C compilers before there was a C standard. They had bugs.
- MaulingMonkey 10y ago
  > There is a difference between "complies with the standard" and "is bug free". You're not wrong - but the dividing line between bug and feature request is subjective, and just how much (meaningful) difference between the two there is depends on the authors of the compiler. If you compile with -fno-strict-aliasing and the optimizer breaks your code based solely on strict aliasing violations anyways, by all means, report that as a bug. If you use a compiler that has no -fno-strict-aliasing equivalent, by all means, switch to a better compiler when they WONTFIX your feature request.
GTP 10y ago
Of course if the compiler has a certain behavior I have to deal with it, I just feel that certain optimizations based on undefined behavior are too aggressive, later this evening I will maybe write in more detail about this in anoter comment below.
- to3m 10y ago
  My favourite UB-related links: "These people simply don't understand what C programmers want": https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWi... "please don't do this, you're not producing value": http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html "Everyone is fired": http://web.archive.org/web/20160309163927/http://robertoconcerto.blogspot.com/2010/10/strict-aliasing.html http://web.archive.org/web/20160309163927/http://robertoconc... (EDIT: this one just gets better every time I read it...) I also found a new one thanks to the comments here, which you can find elsewhere in the comments - but I'll add a link to it here anyway, for good measure: "No sane compiler writer would ever assume it allowed the compiler to 'do anything' with your code": http://article.gmane.org/gmane.os.plan9.general/76989 http://article.gmane.org/gmane.os.plan9.general/76989
  - kbenson 10y ago
    OMG, that first link is golden. It starts off by an email from DJB no less, which includes this snippet: I should note that this plan, throwing away gcc and clang in favor of a boring C compiler, isn't the only possible response to these types of security holes. Here are several other responses that I've seen: * Attack the messenger. "This code that you've written is undefined, so you're not allowed to comment on compiler behavior!" The most recent time I saw this, another language lawyer then jumped in to argue that the code in question _wasn't_ undefined---as if this side discussion had any relevance to the real issue. And to top it off, below Kurt Roeckx explains to someone what part of the problem is: The undefined behaviour of C is deliberate so that compilers can make optimazations. They assume you write code that only has defined meaning and generate code for that defined meaning. That means for instance that if you add 2 signed integers they're going to assume it doesn't overflow and then for instance make assumptions based on that on wether other code ever going to be executed or not. Niiice. This exact scenario is what happened and it's given as an example of problematic optimization of undefined behavior by compilers. If I felt it was pointless to really expect any change before, I definitely do now. I'm definitely favoriting your comment so I can find it easily later.

mpweiher 10y ago

There is a difference between "complies with the standard" and "is bug free". There were C compilers before there was a C standard. They had bugs.

MaulingMonkey 10y ago
> There is a difference between "complies with the standard" and "is bug free". You're not wrong - but the dividing line between bug and feature request is subjective, and just how much (meaningful) difference between the two there is depends on the authors of the compiler. If you compile with -fno-strict-aliasing and the optimizer breaks your code based solely on strict aliasing violations anyways, by all means, report that as a bug. If you use a compiler that has no -fno-strict-aliasing equivalent, by all means, switch to a better compiler when they WONTFIX your feature request.

GTP 10y ago

Of course if the compiler has a certain behavior I have to deal with it, I just feel that certain optimizations based on undefined behavior are too aggressive, later this evening I will maybe write in more detail about this in anoter comment below.

to3m 10y ago
My favourite UB-related links: "These people simply don't understand what C programmers want": https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/#!msg/boring-crypto/48qa1kWi... "please don't do this, you're not producing value": http://blog.metaobject.com/2014/04/cc-osmartass.html http://blog.metaobject.com/2014/04/cc-osmartass.html "Everyone is fired": http://web.archive.org/web/20160309163927/http://robertoconcerto.blogspot.com/2010/10/strict-aliasing.html http://web.archive.org/web/20160309163927/http://robertoconc... (EDIT: this one just gets better every time I read it...) I also found a new one thanks to the comments here, which you can find elsewhere in the comments - but I'll add a link to it here anyway, for good measure: "No sane compiler writer would ever assume it allowed the compiler to 'do anything' with your code": http://article.gmane.org/gmane.os.plan9.general/76989 http://article.gmane.org/gmane.os.plan9.general/76989
- kbenson 10y ago
  OMG, that first link is golden. It starts off by an email from DJB no less, which includes this snippet: I should note that this plan, throwing away gcc and clang in favor of a boring C compiler, isn't the only possible response to these types of security holes. Here are several other responses that I've seen: * Attack the messenger. "This code that you've written is undefined, so you're not allowed to comment on compiler behavior!" The most recent time I saw this, another language lawyer then jumped in to argue that the code in question _wasn't_ undefined---as if this side discussion had any relevance to the real issue. And to top it off, below Kurt Roeckx explains to someone what part of the problem is: The undefined behaviour of C is deliberate so that compilers can make optimazations. They assume you write code that only has defined meaning and generate code for that defined meaning. That means for instance that if you add 2 signed integers they're going to assume it doesn't overflow and then for instance make assumptions based on that on wether other code ever going to be executed or not. Niiice. This exact scenario is what happened and it's given as an example of problematic optimization of undefined behavior by compilers. If I felt it was pointless to really expect any change before, I definitely do now. I'm definitely favoriting your comment so I can find it easily later.