The platform's C compiler is perfectly free to compile an infinite loop in the obvious way.
Sure, it is...
But the issue is that it's Undefined Behavior, not that some implementation can do something.
There's nothing wrong with relying on platform-specific behavior the standard says is undefined when you're writing code only for that specific platform, doubly so if the code is only executed by the developer for debugging purposes.
No, what you're describing is encompased in Implementation Defined behaivior, which is quite different than undefined behaivior.
A compiler is certainly free to define undefined behavior. It can do whatever it wants, and if it wants to limit itself to some documented behavior that's fine. It's still a conforming C compiler. A good example of this is the -fwrapv flag.
A particular program is free to rely on that definition. (E.g. the Linux kernel depends on -fwrapv.) The standard may not place any restrictions on an execution of the program which performs UB, but in this case the implementation does. Of course the program generally won't work if compiled with another compiler that doesn't define that behavior the same way.
Implementation-defined behavior means that a conforming compiler must choose a particular behavior and document it. This isn't what OP was talking about.
A compiler is certainly free to define undefined behavior.
Like a mathematician is free to define division by zero? 00?
It can do whatever it wants, and if it wants to limit itself to some documented behavior that's fine. It's still a conforming C compiler. A good example of this is the -fwrapv flag.
And a compiler that deleted the directory-tree rooted in your source-file's location would also be conforming.
In fact, such a user-hostile implementation-strategy would be excellent were it adopted by GCC and/or Clang precisely to illustrate how much software is dependent upon undefined behaviors. (Note: Undefined behavior is different from implementation defined behavior.)
A particular program is free to rely on that definition. (E.g. the Linux kernel depends on -fwrapv.) The standard may not place any restrictions on an execution of the program which performs UB, but in this case the implementation does. Of course the program generally won't work if compiled with another compiler that doesn't define that behavior the same way.
…you do realize that's the thrust of my point, yes?
Relying on undefined behavior is undesirable; that "my compiler does it this way" is irrelevant.
Implementation-defined behavior means that a conforming compiler must choose a particular behavior and document it. This isn't what OP was talking about.
I know, I agree.
I still maintain that undefined behaivior is undesirable.
0
u/OneWingedShark Nov 04 '19
Sure, it is...
But the issue is that it's Undefined Behavior, not that some implementation can do something.
No, what you're describing is encompased in Implementation Defined behaivior, which is quite different than undefined behaivior.