5 ms·

I don't know why you think my reply is a joke. The person I replied to basically said (paraphrasing) "compilers which optimize based on undefined behavior and f

I don't know why you think my reply is a joke. The person I replied to basically said (paraphrasing) "compilers which optimize based on undefined behavior and follow the standards are written by idiots", and I don't think that's accurate by any stretch of the imagination. Now, if you want to talk about changes that should perhaps be made to the standards, that's a different discussion all together (and also has nothing to do with intelligence, since the UB in the standard today is there to facilitate portability and optimizations, both of which are highly important to C and C++).

geocar 10y ago
> The person I replied to basically said (paraphrasing) "compilers which optimize based on undefined behavior and follow the standards are written by idiots" That's not what I said, it's not what I meant, and I don't think a reasonable person reading my statement would interpret it that way. That you think I'm stupid simply because you didn't understand what I meant, is a common programmer trait, and I don't think it's a good one.
- jjnoakes 10y ago
  Where did I say I thought you were stupid?
- lawnchair_larry 10y ago
  I think I understand your sentiment, but it doesn't apply here. Folks arguing technical correctness in the context of compilers and the C standards are not doing so in order to be pedantic over hypotheticals. Being "technically correct" is important in C because compiler authors reasonably take many liberties in order to improve both compile-time and run-time performance, not to mention reducing cost and complexity of developing the compiler itself. C makes certain guarantees, and compilers will take those for granted where it benefits them, rather than conservatively analyze for situations that are theoretically impossible. You can't say a compilers is dumb because the user gave it invalid code, and in no way is this hiding behind technicalities. It's also not much of a stretch to say that invoking undefined behavior can do things like delete everything on your hard drive. In fact, I've seen it happen many times. Any memory corruption exploit fundamentally relies on the fact that the author invoked undefined behavior. Although it may be undefined, it's still deterministic, so an attacker can construct an input that abuses the failure modes of your particular implementation to run arbitrary code of their choosing, like spawning a shell process and binding it to a port, or fetching some malware. C guarantees that none of this can happen, but when you don't follow the rules of C, they really do mean it when they say anything can happen. It's not because the compiler authors are being trolls and feel entitled to delete your files or launch a rocket out of spite. It's because your machine is now executing who-knows-what.
  - geocar 10y ago
    Now it's definitely specified that a compiler can interpret this: void*x = trk->x; if(!trk) return 0; return doit(x); as: return doit(trk->x); but is that right? Compiler writers can argue that this kind of optimization is useful because it makes other kinds of optimizations easier to implement, but the argument isn't that it's "technically correct" so they must. They have to argue on the merits of the decision, and if they fail to be convincing, people will find other solutions. The DNS specification required clients use source port 53. I think this is dumb because it made it easy to spoof DNS requests -- simply generate 30k UDP packets in a short period of time for a domain name that is commonly requested (like yahoo.com) on a DNS server that's popular (like opendns). If only clients would use a random source port, the number of packets goes into the billions. A few DNS clients ignored the specification because it was wrong, but a few DNS clients stood their ground insisted that it was specified so it was right. I remember the smear campaign referring to one of those secure DNS clients as "not standard compliant". Brutish, but it was effective: Some people remained insecure for a very long time simply because they trusted the standardization process as right and truth.
kbenson 10y ago
A major point of the comment was that being technically correct isn't useful if all you've done is ignore the actual problem in lieu of a small subset of it that doesn't actually help in any way. You then proceeded to call out a small subset of the comment and yes, you were technically correct. You also ignored the actual point of the comment and didn't really contribute anything to because of it, thus doing exactly what the comment was referring to. > The person I replied to basically said (paraphrasing) "compilers which optimize based on undefined behavior and follow the standards are written by idiots" That's not what was said. What was said is that if someone continues to hide behind technicalities rather than addressing the problem problem, then that person is not worth talking to. If you view your original reply in that light...
- jjnoakes 10y ago
  > then that person is not worth talking to That's a highly charitable reading of what was written. I responded to only part of the comment because only part of the comment offended me: "I'll find someone smarter." Sure, if one ignores the hyperbole (like a compiler deleting all of your files compiling your UB source code, because that ever happened), some of the idea has merit. But the expression of that core idea was not done well. But I ignored all of that. The idea that a compiler author must be mentally deficient in some way for following the language standard is absurd. Technical correctness should not be the final word in any discussion (and I never said it was), but calling someone "not smart" for being technically correct in a situation where technical correctness has a lot of value (even if you are focused on the drawbacks) in a comment doesn't really deserve a complete and thoughtful reply.
  - kbenson 10y ago
    > That's a highly charitable reading of what was written. It is. I also think a case could be made that if someone can't get past a technicality when repeatedly asked to, they are lacking in intelligence in one aspect or another, or are purposefully being obstructive. Note that "find someone smarter" doesn't necessarily mean "you are stupid". It does imply that further discussion with this person on this topic will be pointless though. > I responded to only part of the comment because only part of the comment offended me: "I'll find someone smarter." I submit that perhaps because of the greater context and your own views, you might have read more into the words used that strictly called for. I think the original comment is essentially saying "If I keep saying I have a real problem and you keep deferring that it doesn't matter because of some technicality, talking to you is a waste of my time," albeit in slightly more colorful language.
Pxtl 10y ago
You made a correction on a technicality of a post complaining about our discipline's fastidious obsession with correcting technicalities.

geocar 10y ago

> The person I replied to basically said (paraphrasing) "compilers which optimize based on undefined behavior and follow the standards are written by idiots" That's not what I said, it's not what I meant, and I don't think a reasonable person reading my statement would interpret it that way. That you think I'm stupid simply because you didn't understand what I meant, is a common programmer trait, and I don't think it's a good one.

jjnoakes 10y ago
Where did I say I thought you were stupid?
lawnchair_larry 10y ago
I think I understand your sentiment, but it doesn't apply here. Folks arguing technical correctness in the context of compilers and the C standards are not doing so in order to be pedantic over hypotheticals. Being "technically correct" is important in C because compiler authors reasonably take many liberties in order to improve both compile-time and run-time performance, not to mention reducing cost and complexity of developing the compiler itself. C makes certain guarantees, and compilers will take those for granted where it benefits them, rather than conservatively analyze for situations that are theoretically impossible. You can't say a compilers is dumb because the user gave it invalid code, and in no way is this hiding behind technicalities. It's also not much of a stretch to say that invoking undefined behavior can do things like delete everything on your hard drive. In fact, I've seen it happen many times. Any memory corruption exploit fundamentally relies on the fact that the author invoked undefined behavior. Although it may be undefined, it's still deterministic, so an attacker can construct an input that abuses the failure modes of your particular implementation to run arbitrary code of their choosing, like spawning a shell process and binding it to a port, or fetching some malware. C guarantees that none of this can happen, but when you don't follow the rules of C, they really do mean it when they say anything can happen. It's not because the compiler authors are being trolls and feel entitled to delete your files or launch a rocket out of spite. It's because your machine is now executing who-knows-what.
- geocar 10y ago
  Now it's definitely specified that a compiler can interpret this: void*x = trk->x; if(!trk) return 0; return doit(x); as: return doit(trk->x); but is that right? Compiler writers can argue that this kind of optimization is useful because it makes other kinds of optimizations easier to implement, but the argument isn't that it's "technically correct" so they must. They have to argue on the merits of the decision, and if they fail to be convincing, people will find other solutions. The DNS specification required clients use source port 53. I think this is dumb because it made it easy to spoof DNS requests -- simply generate 30k UDP packets in a short period of time for a domain name that is commonly requested (like yahoo.com) on a DNS server that's popular (like opendns). If only clients would use a random source port, the number of packets goes into the billions. A few DNS clients ignored the specification because it was wrong, but a few DNS clients stood their ground insisted that it was specified so it was right. I remember the smear campaign referring to one of those secure DNS clients as "not standard compliant". Brutish, but it was effective: Some people remained insecure for a very long time simply because they trusted the standardization process as right and truth.

kbenson 10y ago

A major point of the comment was that being technically correct isn't useful if all you've done is ignore the actual problem in lieu of a small subset of it that doesn't actually help in any way. You then proceeded to call out a small subset of the comment and yes, you were technically correct. You also ignored the actual point of the comment and didn't really contribute anything to because of it, thus doing exactly what the comment was referring to. > The person I replied to basically said (paraphrasing) "compilers which optimize based on undefined behavior and follow the standards are written by idiots" That's not what was said. What was said is that if someone continues to hide behind technicalities rather than addressing the problem problem, then that person is not worth talking to. If you view your original reply in that light...

jjnoakes 10y ago
> then that person is not worth talking to That's a highly charitable reading of what was written. I responded to only part of the comment because only part of the comment offended me: "I'll find someone smarter." Sure, if one ignores the hyperbole (like a compiler deleting all of your files compiling your UB source code, because that ever happened), some of the idea has merit. But the expression of that core idea was not done well. But I ignored all of that. The idea that a compiler author must be mentally deficient in some way for following the language standard is absurd. Technical correctness should not be the final word in any discussion (and I never said it was), but calling someone "not smart" for being technically correct in a situation where technical correctness has a lot of value (even if you are focused on the drawbacks) in a comment doesn't really deserve a complete and thoughtful reply.
- kbenson 10y ago
  > That's a highly charitable reading of what was written. It is. I also think a case could be made that if someone can't get past a technicality when repeatedly asked to, they are lacking in intelligence in one aspect or another, or are purposefully being obstructive. Note that "find someone smarter" doesn't necessarily mean "you are stupid". It does imply that further discussion with this person on this topic will be pointless though. > I responded to only part of the comment because only part of the comment offended me: "I'll find someone smarter." I submit that perhaps because of the greater context and your own views, you might have read more into the words used that strictly called for. I think the original comment is essentially saying "If I keep saying I have a real problem and you keep deferring that it doesn't matter because of some technicality, talking to you is a waste of my time," albeit in slightly more colorful language.

Pxtl 10y ago

You made a correction on a technicality of a post complaining about our discipline's fastidious obsession with correcting technicalities.