3 ms·

> There is no good reason for a C99 implementation behaving in a C90 compatibility mode to simply drop non-conflicting C99 requirements and revert a behavior su

> There is no good reason for a C99 implementation behaving in a C90 compatibility mode to simply drop non-conflicting C99 requirements and revert a behavior such as this. A compatibility with a code which depends on a behaviour of a previous version of the compiler is a reason enough. If compatibility is dropped you now have a very subtle bug which is hard to discover and understand unless you read about that particular GNUism before. It's also a perfect setup for Schrödinger's bug.

int_19h 5y ago
There's no compatibility requirement here, because the old behavior is UB (both in theory and in practice).
- monocasa 5y ago
  Apparently the compiler writers thought there was, and the compiler writers get to define semantics above and beyond what's in the C spec.
- _kst_ 5y ago
  The old behavior is not undefined behavior. In C90, falling off the end of main() returns an undefined status to the environment. The behavior of the program is otherwise well defined. It's true that an implementation that follows the C99 and later requirements also conforms to the looser C90 requirements. But if a compiler chooses not to do so, I don't see it as a bug. If I use "-std=c90" or equivalent, I'm specifically not asking for C99 or later semantics; I want the compiler to conform to the C90 standard. If I use "-std=c90" and my program assumes C99 or later semantics, that's a bug in my program, not in the compiler.
  - ncmncm 5y ago
    If you specify "-std=c90", all you are saying, for this case, is that you don't care what value is returned. If you don't care, then zero is as good as any other value, so there is no reason for the compiler to have a different code path for that case. There are always good reasons not to have poorly exercised code paths.
    - _kst_ 5y ago
      Earlier versions of gcc didn't support C99 or later at all. Making reaching the closing "}" do an implicit "return 0;" was a new language feature, and it was tied to the (non-default) "-std=c9x" or later "-std=c99" option. Some existing code might have depended (foolishly IMHO) on the arbitrary non-zero value returned from main. Even if that's not the case, if you're programming in C90, having your program indicate that it failed is a good reminder to add the "return 0;". I've never bothered to check exactly how "gcc -std=c90" handles this, but having it intentionally return a non-zero value in C90 mode would have been a good choice, since it would make the bug of omitting the return or exit more visible. gcc can also warn about not returning a value from a non-void function. Whatever it returns in C90 mode, it's not a bug, and so the gcc maintainers have probably decided that they have more important things to do than change the behavior. They might have made a different choice if they were implementing "-std=c90" from scratch today.
      - ncmncm 5y ago
        What do you suppose has changed between when they did, and today, that could lead to a different choice?

int_19h 5y ago

There's no compatibility requirement here, because the old behavior is UB (both in theory and in practice).

monocasa 5y ago
Apparently the compiler writers thought there was, and the compiler writers get to define semantics above and beyond what's in the C spec.
_kst_ 5y ago
The old behavior is not undefined behavior. In C90, falling off the end of main() returns an undefined status to the environment. The behavior of the program is otherwise well defined. It's true that an implementation that follows the C99 and later requirements also conforms to the looser C90 requirements. But if a compiler chooses not to do so, I don't see it as a bug. If I use "-std=c90" or equivalent, I'm specifically not asking for C99 or later semantics; I want the compiler to conform to the C90 standard. If I use "-std=c90" and my program assumes C99 or later semantics, that's a bug in my program, not in the compiler.
- ncmncm 5y ago
  If you specify "-std=c90", all you are saying, for this case, is that you don't care what value is returned. If you don't care, then zero is as good as any other value, so there is no reason for the compiler to have a different code path for that case. There are always good reasons not to have poorly exercised code paths.
  - _kst_ 5y ago
    Earlier versions of gcc didn't support C99 or later at all. Making reaching the closing "}" do an implicit "return 0;" was a new language feature, and it was tied to the (non-default) "-std=c9x" or later "-std=c99" option. Some existing code might have depended (foolishly IMHO) on the arbitrary non-zero value returned from main. Even if that's not the case, if you're programming in C90, having your program indicate that it failed is a good reminder to add the "return 0;". I've never bothered to check exactly how "gcc -std=c90" handles this, but having it intentionally return a non-zero value in C90 mode would have been a good choice, since it would make the bug of omitting the return or exit more visible. gcc can also warn about not returning a value from a non-void function. Whatever it returns in C90 mode, it's not a bug, and so the gcc maintainers have probably decided that they have more important things to do than change the behavior. They might have made a different choice if they were implementing "-std=c90" from scratch today.
    - ncmncm 5y ago
      What do you suppose has changed between when they did, and today, that could lead to a different choice?