Re: More C type errors by default for GCC 14

[Eli Schwartz <eschwartz93@gmail.com>]

On 5/10/23 11:56 PM, Po Lu wrote:
> Eli Schwartz <eschwartz93@gmail.com> writes:
> 
>>> Unfortunately, we do not have the source code for our compiler.  Would
>>> you care to ask people here to restore `gcc -traditional'?
>>
>>
>> This would appear to be a self-inflicted wound. If I understand the
>> chain of events properly...
> 
> The chain of events actually is:
> 
>   - The code was originally written for the BSD Unix cc.
>   - Eventually, it started to be built with GCC, with -traditional.
>   - GCC removes -traditional.
>   - We are forced to find another C comppiler.


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


> Note that I wasn't where I am when this started, so everything above is
> second hand knowledge.
> 
> And finally, this:
> 
>>   - to avoid making it produce invalid results, you hack your linker
> 
> Which is essentially link-time lint, and not related to the subject at
> hand.  I only mentioned it to make a point, which is that people writing
> traditional C in this day and age are unlikely to make any mistakes
> doing so.


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.


>> You'd rather hack your compiler, but you cannot do it because you
>> purchased a proprietary compiler and didn't purchase the rights to its
>> source code.
>>
>> (BTW, there's a FOSS compiler that you can hack on if you like.)
> 
> Which sadly does not support the code which we need to compile.
> Clearly, turning GCC into a K&R compiler is not a very welcome idea
> around here, so why would we hack on it?


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?


>> That's all fine and well, you do you. What I do not understand is, two
>> things.
>>
>> First of all, why are you calling this "traditional C"? It is not
>> "traditional C". It isn't C. It is not-C.
> 
> When the file names for the source files end with `.c' and `.h', and the
> compiler is named `cc' and `acomp', it is C.  It just isn't Standard C.


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.

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


>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
> 
> Because decisions arbitrarily made on GCC's part will simply result in
> even more people deciding to find some other compiler.
> 
> The point being that people sufficiently dedicated to their existing
> code to not have changed in over 30 years will not respond to such
> changes by changing their code.  They are much more likely to look for
> some other compiler instead.


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.

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?


>> And implicit-function-declaration does not have the same problem as
>> -traditional, because implicit-function-declaration ***WILL*** have a
>> flag that permits people who are users of GCC, and just want
>> implicit-function-declaration back.
> 
> And remember that `-traditional' DID exist for a certain amount of time.
> Then it was removed.  So in addition to annoying a lot of people, what
> guarantees that -Wno-implicit will not be removed in the future, after
> the proposed changes are made?


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.

...

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.

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.


-- 
Eli Schwartz