Re: More C type errors by default for GCC 14

[Po Lu <luangruo@yahoo.com>]

Gabriel Ravier <gabravier@gmail.com> writes:

> It's "extra work" to add 10 characters to a Makefile, but normal to
> add random faulty declarations everywhere ? 

You're assuming that people are willing to edit Makefiles, which is all
kinds of pain, and then put up with a complete recompile of whatever
software is being built because CFLAGS changed.

> I could only imagine someone doing this if they're being either
> extremely uninformed, extremely restricted (e.g. no change to any
> configuration files, no pragmas to disable the errors and not even
> having 10 seconds to look up the correct function prototype) or
> deliberately obtuse.

Under time restrictions, or being extremely uninformed, yes.  These are
precisely the situations that many GCC users are under.

> Now you're the one playing with words. That, or you have a complete
> lack of understanding of extremely common English expressions, which
> you may want to work on as you will otherwise inevitably have large
> problems effectively communicating anything with people on this list.

That my response was so short should have made my point clear, right?
It's a tangent.  I don't claim to speak for anyone other than myself,
and Eli Schwartz implied that I was.

> The "definition of GCC" used here is in a more general sense, i.e. the
> GCC project and the people involved in it that would be considered
> generally representative of it.

But we're debating behavior of the C translator itself, and the
definition of that is clear: the code which comprises the C translator,
cc1, and its frontend, gcc.  What any person thinks, AFAIK, is not
really relevant.

> In fact, so far on this thread I've seen almost nobody on your side of
> the argument, save for a very few extremely loud people repeating the
> same arguments over and over.

From my perspective, I also see only a few extremely loud people
repeating the same arguments over and over.  But how many times have I
mentioned that?  The number of people in this thread is too small to
conclude anything from.

> So far I've seen only a single minor GCC contributor arguing the
> behavior should be kept as-is - pretty much everyone else agrees the
> behavior should be changed. In fact, I've talked to many people who
> are not currently posting in this thread, who consider that the
> default should be changed, and are watching in consternation as a few
> people appear to be trying to hold back the entire community with
> extremely bad defaults.

In this entire thread of long winded flames, I've not heard a single
reasonable attempt to explain the following points of contention:

  1. Why GCC gets to judge whether or not users' code is correct or not.

  2. How implicit function declarations are different from function
     declarations with no parameter specification, and why it is
     reasonable to make the former an error while allowing the latter.

     By extension, why implicit function declarations are ``always
     wrong'', as some people have been claiming.

     (Aside from, of course, that ``the Standard allows''.
      But the Standard also allows implicit function declarations and
      int.)

  3. How implicit int makes the meaning of a program unclear, in any
     way, with the exception of C2X and auto.  I have not ever seen auto
     explicitly used as a storage class specifier, so from my
     perspective that is not really a problem.

  4. Why people under various time or (mental) energy constraints will
     not simply insert the necessary declarations to pacify GCC, which
     will be as correct as the implicit declaration was.

> In the "C Extensions" section?

The `C Extensions' node is not the only document describing extensions
accompanying the translator.

> By the same line of argumentation, any accepts-invalid is actually not
> a bug and should instead be considered a documentation bug that should
> be fixed by altering the documentation rather than fixing the actual
> bug (given that you appear to consider that making GCC not accept code
> that it previously accepted by default is something that should never
> be done). I hope you understand that's not a reasonable line of
> argumentation.

No, because this is not a bug where GCC accepts invalid code in the
first place.  This is behavior which was explicitly introduced into GCC,
but not documented in a more appropriate location in the manual.

> To be honest, I'd be inclined to consider the current behavior a
> longstanding bug that's been wrongly considered to be a WONTFIX for
> many years, and that we're only now getting around to fixing, if you
> really want to go down this line of argumentation.

Where is the ticket/thread on {Bugzilla,gnu.gcc.bug,gcc-bugs}?  Anyway,
I've never argued anything to this effect.  In fact, I would be more
inclined to consider the decision to not consider this a bug the
decision that explicitly defined it as behavior of the C translator.

> Actually, now that I think about it, what are you actually trying to
> get from this conversation ? If you're unsatisfied with a lack of
> commitment from the maintainers to maintain a `-fpermissive` option
> indefinitely, it seems like you can't possibly be satisfied with the
> current situation, either. It seems like what you actually want is an
> eternal commitment from the GCC developers to never ever change the
> behavior of GCC ever in any way that could ever break any of your old
> broken code...

I don't want anything, seeing as I've been using GCC less and less over
the years (for this and other reasons.)  I'm just throwing in my two or
so cents.