Re: More C type errors by default for GCC 14

[Po Lu <luangruo@yahoo.com>]

Eli Schwartz <eschwartz93@gmail.com> writes:

> Right, this is what I said. Although your bullet points 1 and 2 don't
> really have much of anything to do with it.
>
> In between points 3 and 4, I noted that you wish to *use* such bad code.
> I didn't say you wish to write it, merely that you wish to use it
> (without judging when it was written).

[...]

> Absolutely! It's a very good point. It's a point that people writing
> traditional not-C in this day and age are doing so with highly complex
> toolchains they have personally written to do things that no non-bespoke
> toolchain does. As such, they are unaffected by any and all decisions
> GCC makes. But if they were affected by such decisions, they would have
> the technical knowledge to modify GCC to suit themselves.

Upper management types performed a cost analysis and decided that it
would be more appropriate to license another C compiler.  Please don't
expect that only technical ability affects decisions made in the real
world.

> But your bespoke toolchain did not support the code which you need to
> compile either. That's why you began hacking on it at all, to suit your
> needs.
>
> So if neither GCC nor your bespoke toolchain support the code you need
> to compile, and you must modify *something* to suit yourself, then it is
> definitely possible to do it for GCC instead.
>
> I don't see what the welcome for making these modifications into the
> default flagship experience for the entire free software ecosystem, has
> to do with your being welcome to hack on GCC for your own personal use.
>
> Do you feel welcome by your proprietary vendor, who refuses to let you
> touch it at all by withholding source code?

No, I do not.  I can not speak for my management.

But I also do not feel any welcome from a group of developers who are
interested in breaking other code, some of which I have written for
myself, and then religiously defend their decisions.

In short, I do not like being told what to do with my own code!

> BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to
> /usr/bin/python.
>
> ...
>
> No, the criteria for whether something constitutes a given programming
> language are not "the file extension says so" or "the compiler name says
> so".
>
> A programming language is defined by the syntax and meaning of that
> programming language.

OK, and the Portable C Compiler from Bell Labs followed one such
definition of its syntax and meaning.

ANSI and ISO simply define several such variants of the C language,
collectively known as Standard C.  1st edition K&R defines another, and
each compiler, in practice, defines its own.  Just like there are
different varieties of English, or perhaps German.

> (If we were to replace this conversation with a definition of what
> constitutes python, then as a scripted language, all files without file
> extensions could be python scripts. And similarly, people play
> interesting games with C files by naming them unconventional names and
> passing -xc to the compiler. File extension autodetection isn't everything.)

This is pure pedantry.  My point is:

  If it looks like a duck, and quacks like a duck, then it is a duck.

or, IOW:

  If it looks like C, compiles in a C compiler, then it is C.

> Well no, because if they are sufficiently dedicated to their existing
> code to not have changed in over 30 years then they are writing c89 code
> and passing -std=c89, and this is acceptable as far as GCC is concerned
> and their code will still compile.

They are not writing ``C89'' code.  They are writing ``GNU99'', or perhaps
``GNU11'' code.

> So they won't feel inclined to find some other compiler, and quite
> frankly, if they were doing the right thing in accordance with the
> standard way to use the language they prefer to use, then they probably
> will not notice that GCC changed anything?

What gives you the right to dictate what the Right Thing is and what is
not?

> What guarantees of the future do you have for anything?
>
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
>
> What guarantees do you have that GCC will still be run by the current
> maintainers?
>
> What guarantees do you have that GCC will still be maintained at all?
>
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
>
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
>
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.

You are arguing to absurdity.

> I think that what-ifs aren't the most productive use of our time. The
> current proposal provides for -std=c89 and similar, so the current
> proposal does not cause current GCC users to be unable to use GCC after
> the proposed change.

Perhaps you must try writing a program which strictly conforms to the
Standard, since you seem to be asking everyone to write in such a way.

My point is that there is a very significant body of economically
valuable code written in the dialect of C actually implemented by GCC,
as it stands right now, just as there is a significant (albiet not so
much) body of traditional C (K&R) code.

If GCC is no longer able to compile such code, it will attract the
legitimate anger of its users.  And making users angry is not productive
in any way.

> If a future proposal causes current GCC users to be unable to use GCC
> after the future proposal is implemented, then, and only then, should we
> worry about whether it will be possible to use GCC. Then, and only then,
> will a threat to prevent doing so have actually materialized.

Parse error.