4 ms·

The standard says the compiler is allowed to make that change. The standard says the programmer writing that piece of code is wrong. So no, it's not a bug in th

The standard says the compiler is allowed to make that change. The standard says the programmer writing that piece of code is wrong. So no, it's not a bug in the compiler, the compiler is complying with the standard. You could make a case that it's a bug in the standard though :-)

mpweiher 9y ago
No, the compiler is interpreting the standard in a particular way. It doesn't have to do this. I had a C compiler (paid for it) before there was a C standard. So in your opinion, this compiler could do anything at all and nothing could possibly ever be a bug. UPDATE: A lot of mindless downvotes, but no actual substantive rebuttals. As expected.
- kutkloon7 9y ago
  Well, of course the author of the compiler could argue that the compiler is bug-free, and all behavior is intentional. While this would be laughable in most cases, there is no 'hard evidence' that this is not the case. A standard is needed in some cases where there is no 'obvious' behavior. I think this is the way that the 'Ruby standard' is defined, by a reference implementation which is assumed to be bug-free. About the interpretation of the standard: this is probably true, but this kind of technical documents is meant to be mono-interpretable, if you know what I mean. Ultimately there might be a few limitations which you don't encounter in practice (if you give your variables names of more than 4k characters, I doubt if it will compile), so you might argue this is an 'interpretation of the standard'. I would argue that in such a case technically, the compiler doesn't comply with the standard, but for all purposes and intents, it does (and so, in practice no one would doubt that the compiler complies to the standard).
to3m 9y ago
It would be complying with the standard if it compiled the whole program into one single call to abort! And yet it didn't do that. I wonder why not.
- caf 9y ago
  The code in question is not ill-defined over all inputs - it has well-defined behaviour as long as the offset in question doesn't exceed the size of the object that it is being used to address.
  - lawnchair_larry 9y ago
    Actually, invoking undefined behavior anywhere in the code, even unreachable code, means the entire program is invalid. Including for all inputs. The reason it doesn't simply abort is because compiler authors don't go out of their way to do extra work for no reason.
    - zAy0LfpBZLC8mAC 9y ago
      > Actually, invoking undefined behavior anywhere in the code, even unreachable code, means the entire program is invalid. Erm ... nope. If code is unreachable, it can, by definition, not exhibit undefined behaviour. > The reason it doesn't simply abort is because compiler authors don't go out of their way to do extra work for no reason. Well, true, but the primary reason is that there are parts of the input domain for which the behaviour of the code is actually defined, and it's not defined to mean a call to abort(). The mere possibility to call some code at runtime with values for which the behaviour is undefined does not make the code's semantics completely undefined.

mpweiher 9y ago

No, the compiler is interpreting the standard in a particular way. It doesn't have to do this. I had a C compiler (paid for it) before there was a C standard. So in your opinion, this compiler could do anything at all and nothing could possibly ever be a bug. UPDATE: A lot of mindless downvotes, but no actual substantive rebuttals. As expected.

kutkloon7 9y ago
Well, of course the author of the compiler could argue that the compiler is bug-free, and all behavior is intentional. While this would be laughable in most cases, there is no 'hard evidence' that this is not the case. A standard is needed in some cases where there is no 'obvious' behavior. I think this is the way that the 'Ruby standard' is defined, by a reference implementation which is assumed to be bug-free. About the interpretation of the standard: this is probably true, but this kind of technical documents is meant to be mono-interpretable, if you know what I mean. Ultimately there might be a few limitations which you don't encounter in practice (if you give your variables names of more than 4k characters, I doubt if it will compile), so you might argue this is an 'interpretation of the standard'. I would argue that in such a case technically, the compiler doesn't comply with the standard, but for all purposes and intents, it does (and so, in practice no one would doubt that the compiler complies to the standard).

to3m 9y ago

It would be complying with the standard if it compiled the whole program into one single call to abort! And yet it didn't do that. I wonder why not.

caf 9y ago
The code in question is not ill-defined over all inputs - it has well-defined behaviour as long as the offset in question doesn't exceed the size of the object that it is being used to address.
- lawnchair_larry 9y ago
  Actually, invoking undefined behavior anywhere in the code, even unreachable code, means the entire program is invalid. Including for all inputs. The reason it doesn't simply abort is because compiler authors don't go out of their way to do extra work for no reason.
  - zAy0LfpBZLC8mAC 9y ago
    > Actually, invoking undefined behavior anywhere in the code, even unreachable code, means the entire program is invalid. Erm ... nope. If code is unreachable, it can, by definition, not exhibit undefined behaviour. > The reason it doesn't simply abort is because compiler authors don't go out of their way to do extra work for no reason. Well, true, but the primary reason is that there are parts of the input domain for which the behaviour of the code is actually defined, and it's not defined to mean a call to abort(). The mere possibility to call some code at runtime with values for which the behaviour is undefined does not make the code's semantics completely undefined.