Re: More C type errors by default for GCC 14

[Po Lu <luangruo@yahoo.com>]

Eli Schwartz <eschwartz93@gmail.com> writes:

> Does this mean you've conceded the point, and no longer think it is
> written in C++?

No.

> You are correct in reading my sentence, that is indeed what I said.
>
> Aside: you have reiterated "the behavior of the translator itself" over
> and over again, but it hasn't been generally reiterated, or even iterated.

Parse error.

> Repeating this statement won't make it true.

Before you say this, I suggest that you take some time to look at
yourself in a mirror.

> In fact, lots and lots and lots of programs do indeed operate such that
> the documentation specifies how the program shall behave, and when the
> program fails to behave in the manner in which it is documented to
> behave, the program shall be fixed.
>
> We call these failures to behave according to the documentation,
>
>
> Bugs.
>
>
> Occasionally it is also called specification-driven development.
>
> ...
>
> In cases where the documentation says nothing at all, for good or ill,
> the behavior of the program is undefined -- users cannot rely on it, for
> they cannot know what is intended and what is not intended -- in this
> case, the intended behavior must be defined, documented, and
> implemented, and "the program currently does X" gets one vote out of
> many and is not guaranteed to get its way.
>
> Very often in such cases the best user-serving thing to do is to define
> the behavior as "shall not be used, and for legacy reasons if you use it
> it will continue to do X but raise a warning telling you that you are
> required to stop depending on it" and possibly even "it may disappear in
> semver version YYY".

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

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.

> 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.