Po Lu via Gcc <gcc@gcc.gnu.org> writes:

...

> Where is it written that GNU CC follows your so-called
> ``specification-driven development''?

Any development style making documentation a source of truth matches
this principle.  This does not refer to ISO specifications specifically,
though, normally, unless the standard disagrees with reality, as
implicit-... did many years ago, ISO decisions are taken seriously.

> Here is an explanation from one of the original GCC developers.  It
> discusses strict aliasing, but the same principles apply here:
>
> (199909100634.CAA01815@psilocin.gnu.org)
>
>       My comment is similar to Mark's comment.  Documentation, what can
>       we document as working?
>
>   We should not even try to document that these cases work.
>   Documentation is what we do when we add a feature.
>
>   I am not proposing this as a feature, just as a way to avoid evitable
>   trouble for users.  We should not even try to document a class of
>   cases that are "supposed" to work, because I'm not saying these are
>   "supposed" to work.  We should just let them work.
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>       Anway, more questions from me than answers...  Off hand though, if
>       we can make the compiler generate `right' code in more cases, even
>       if the users code is wrong, I think we should probably do it.
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.
>
> and another (199909100634.CAA01812@psilocin.gnu.org):
>
>       However, I have a rather serious objection: it means that users
>       cannot tell whether their code is valid, even according to the GCC
>       rules, without knowing the internals of the compiler.
>
>   This has always been true.  It is true in the current version of GCC
>   with regard to aliasing, even when -fstrict-aliasing is used.  It is
>   part of the nature of C.
>
>   The goal of trying to avoid it is unrealistic and misguided; it can't
>   be done.  So this cannot be a valid reason to reject a change.
>
>       The compiler should continue to aggressively break code that
>       misbehaves in this way.
>
>   This proposes to break users' code, just to bully them into changing
>   it.  That is a callous and harsh attitude towards the users of GCC.
>   No wonder users are angry.  They know that the problems are not due to
>   necessity, but due to callous disregard for them.
>
>   We cannot do everything all users want, and sometimes a maintainer has
>   to say no to users.  "You cannot please everyone," as the saying goes.
>   There are many kinds of reasons which can sometimes be good reasons to
>   say no.
>
>   But maintainers should always say no reluctantly--never eagerly.  We
>   should never aggressively cause trouble for users today, just because
>   someday it might be necessary.  That is like amputating limbs because
>   someday they might be crushed.
>
>   This treatment of users brings shame on the GNU Project.  I ask
>   everyone therefore not to suggest that we should treat users this way.
>
>> Sound familiar? A bit like GCC triggering a warning, telling you that
>> what you're doing is bad and should not be relied on?
>
> A diagnostic message is supposed to inform me of a diagnosis by the
> translator.  The severity of the diagnosis, is, as always, up to the
> user to decide, as long as enough information remains for translation to
> continue.

It is, after this proposal is accepted, still up to the user to decide.
The only difference is that the default would be friendlier to new code
and users and most code that exists today, rather than to very old code
and incorrect code.

Additionally, there isn't enough information to compile.  The compiler
makes up new information to fill in the gaps.

If that definition accepted, most error recovery should be turned into
valid code paths that participate as GNU extensions, for instance,
there's no reason that:

   int f (int x) { x += 10 return x + 123 }

shouldn't compile, as the compiler knows where to insert semicolons to
make it (probably) work.  I'd say that extension is more acceptable than
the ones being proposed into turning into errors by default, since it
isn't very ambiguous, unlike an implicit function declaration or such.

>> But GCC isn't dropping support for it in semver version anything, just
>> guarding its use behind an opt-in flag.
>
> Which is liable to disappear in the future, as many have before it.

It has been 25 years since the addition of -fpermissive to G++.  I'm
optimistic.

Have a lovely day.
-- 
Arsen Arsenović