Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Thu, 11 May 2023, 07:11 Eli Zaretskii via Gcc,  wrote:

> > Date: Wed, 10 May 2023 23:14:20 -0400
> > From: Eli Schwartz via Gcc 
> >
> > Second of all, why is this GCC's problem? You are not a user of GCC,
> > apparently.
>
> He is telling you that removing support for these old features, you
> draw users away from GCC and towards proprietary compilers.
>


Nobody is removing support for them though.



> One of the arguments in this thread _for_ dropping that support was
> that by not rejecting those old programs, GCC draws some users away
> from GCC.  He is telling you that this change will, perhaps, draw some
> people to GCC, but will draw others away from GCC.  The difference is
> that the former group will start using Clang, which is still free
> software (at least some of its versions), whereas the latter group has
> nowhere to go but to proprietary compilers.  So the FOSS community
> will have suffered a net loss.  Something to consider, I think.
>

Yes, because switching to a different compiler is much easier and less
disruptive than [checks notes] adding some additional options to a makefile.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: David Brown 
> Date: Thu, 11 May 2023 08:52:03 +0200
> 
> > But we are not talking about some random code that just happened to
> > slip through cracks as a side effect of the particular implementation.
> > We are talking about code that was perfectly valid, had well-defined
> > semantics, and produced a working program.  I don't care about the
> > former; I do care about the latter.
> 
> How would you know that the code had perfectly valid, well-defined 
> semantics?

The programmer who wants to keep that code will know (or at least
he/she should).

> I've had the dubious pleasure of trying to maintain and update code 
> where the previous developer had a total disregard for things like 
> function declaration - he really did dismiss compiler complaints about 
> implicit function declarations as "only a warning".  The program worked 
> as he expected, for the most part.  But that was despite many functions 
> being defined in one part of the code with one set of parameters (number 
> and type), and called elsewhere with a different set - sometimes more 
> than one selection of parameter types in the same C file.

In this situation, where you take responsibility of a program someone
else wrote, and consider its code to be badly or unsafely written, TRT
is to modify the program to use more modern techniques that you
understand and support.  Compiler warnings and your own knowledge of
valid C will guide you in this.

My problem is not with the situation you described, it's with a case
that the "previous" maintainer remains the current maintainer, and/or
for some reason rewriting the code is either impractical or not the
best alternative for other reasons.

> If a compiler is required to continue to compile every program that a 
> previous version compiled, where the developer was satisfied that the 
> program worked as expected, then the only way to guarantee that is to 
> stop changing and improving gcc.

There should be no such requirement.  If addition of new features or
support for the evolving standards mean GCC must break old UB-style
code, that is fully justified and understandable.  What is _not_
justified, IMO, is breaking old programs without any such technical
reasons, just because we think they are better off broken.  IOW, as
long as being able to compile those old programs in the same old way
doesn't get in the way of being able to compile valid programs, the
old code should remain unbroken.

> I agree that accepting fully correct programs written in K&R C would not 
> limit the future development of gcc.  But how many programs written in 
> K&R C, big enough and important enough to be relevant today, are fully 
> correct?  I'd be surprised if you needed more than one hand to count 
> them.

For the purpose of this discussion, the "how many" question is not
interesting.  If there is an incorrect K&R program, the results and
consequences of this incorrectness are on the maintainers of those
programs, not on the GCC team.  If some of those incorrect programs
break because of some valid development in GCC, so be it.

But the decision to make a warning to be an error is not dictated by
GCC development and its needs to compile valid programs, it is
dictated by other, largely non-technical considerations.  I'm saying
that these considerations are not reasons good enough for breaking
those old programs.

> Continuing to give developers what they expect, rather than what the 
> standards (and gcc extensions) guarantee, is always an issue for 
> backwards compatibility.  Each new version of gcc can, and sometimes 
> does, "break" old code - code that people relied on before, but was 
> actually incorrect.  This is unavoidable if gcc is to progress.

It is indeed unavoidable, and a fact of life.  All I'm saying is that
we as developers should try to minimize these breakages as much as
possible, without hampering new developments too much.

> That is why I suggested that a flag such as "-fold-code" that enables 
> long outdated syntaxes should also disable the kind of optimisations 
> that are most likely to cause issues with old code, and should enable 
> semantics chances to match likely assumptions in such code.  I don't 
> believe in the existence of correct K&R C code - but I /do/ believe in 
> the importance of some K&R C code despite its errors.

The problem, as you well know, is that when a large software package
fails to build, it is not immediately clear what is the reason for
that.  We here discuss a single such reason, but in reality no one
tells you that the build fails because the new version of GCC now
rejects code it accepted in the previous version.  The upgrade that
installed the new GCC will typically update dozens of other system
components, many of which could be the culprit.  Just understanding
that the reason is GCC and its rejection of certain constructs is a
job that can take hours full of frustration and hair-pulling.  This is
what I think we as developers need to avoid as

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.
>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?

None of these result in a whisper-level warning before a severe but
difficult to detect breakage.

>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The code is conforming, it simply relies on extensions to the Standard.
> Implicit int does not break any strictly conforming program, so a C
> implementation implemented it continues to be conforming, along with
> those programs relying on implicit int.  See this wording in the
> Standard:

All of the features in question actively break programs (because they
allow entirely wrong code to be emitted).

>   A conforming implementation may have extensions (including additional
>   library functions), provided they do not alter the behavior of any
>   strictly conforming program.
>
> You are not trying to reject non-conforming C code.  You are, for better
> or worse, trying to impose your personal preferences on users of GCC.

> Let's debate the real problem at hand instead of using the Standard as a
> boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
> good idea.

It is.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu via Gcc  writes:

> Jonathan Wakely via Gcc  writes:
>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:
>>
>>>
>>> And then people will start complaining about GCC unnecessarily
>>> erroring out, which is a compiler bug, since there's no problem
>>> producing correct code in these cases.
>>>
>>
>>
>> What is the correct code for this?
>>
>> void foo(int);
>> void bar() { foo("42"); }
>>
>> Why should this compile?
>
> Because keeping that from compiling will also keep this from compiling:
>
> bar ()
> {
>   extern foo ();
>
>   return foo ("42");
> }

Good.  The above code is nonsense, the chances that foo will be
incorrectly called are high.

>> You keep demanding better rationale for the change, but your argument
>> amounts to nothing more than "it compiles today, it should compile
>> tomorrow".
>
> And so it should.  Because for every invalid piece of code you can think
> of, there are hundereds or thousands of combinations that may as well be
> valid.  For example, on the 68020, vax, or similarly reasonable 32-bit
> machine:
>
> foo (ptr)
> {
>   register char *str;
>
>   str = ptr;
>
>   /* do stuff with str */
>
>   puts (str);
> }
>
> /* In another translation unit.  */
>
> bar ()
> {
>   foo ("42");
> }

What is this meant to produce?

This is, at best, a "works by coincidence", rather than being code
anyone should be writing.

Such code is already written, when building it, pass -fpermissive.
You benefit from the error otherwise.

(and no, this isn't an issue of style, the code in question *does not*
convey sufficient information for the compiler to always do the right
thing)

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 11/05/2023 04:09, Po Lu via Gcc wrote:

jwakely@gmail.com (Jonathan Wakely) writes:


So let's do it. Let's write a statement saying that the GCC developers
consider software security to be of increasing importance, and that we
consider it irresponsible to default to accepting invalid constructs in the
name of backwards compatibility. State that we will make some changes which
were a break from GCC's traditional stance, for the good of the ecosystem.


I'm sorry you think that way.


Given recent pushes to discourage or outright ban the use of memory-safe
languages in some domains, I think it would be good to make a strong
statement about taking the topic seriously. And not just make a statement,
but take action too.

If we don't do this, I believe it will harm GCC in the long run. The vocal
minority who want to preserve the C they're used to, like some kind of
historical reenactment society, would get their wish: it would become a
historical dead end and go nowhere.


Vocal minority? Do you have any evidence to back this claim?

What I see is that some reasonable organizations have already chosen
other C compilers which are capable of supporting their existing large
bodies of C code that have seen significant investment over many years,
while others have chosen to revise their C code with each major change
to the language.

The organizations which did not wish to change their code did not
vocally demand changes to GCC after GCC became unsuitable, but quietly
arranged to license other compilers.

Those that continue write traditional C code know what they are doing,
and the limitations of traditional C do not affect the quality of their
code.  For example, on the Unix systems at my organization, the SGS is
modified so that it will not link functions called through a declaration
with no parameter specification with a different set of parameters than
it was defined with.

Naturally, the modified linker is not used to run configure scripts.



Let's be absolutely clear here - gcc has been, and will continue to be, 
able to compile code according to old and new standards.  It can handle 
K&R C, right through to the cutting edge of newest C and C++ standards. 
It can handle semantic requirements such as two's complement wrapping 
and "anything goes" pointer type conversions - features that a lot of 
old code relies on but which are not documented or guaranteed behaviour 
for the vast majority of other compilers.  It can handle all these 
things - /if/ you pick the correct flags.


With the proposed changes, you can still compile old K&R code with gcc - 
if you give it the right flags.  No features are being removed - only 
the default flags are being changed.  If anyone is changing from gcc to 
other compilers because they think newer gcc does not support older 
code, then they are perhaps doing so from ignorance.


If some users are willing to change to different compilers, but 
unwilling to learn or use new flags in order to continue using their 
existing compiler after it changes its defaults, then perhaps gcc could 
pick different defaults depending on the name used for the executable? 
If it is invoked with the name "gcc-kr", then it could accept K&R code 
by default and have "-std=gnu90" (I believe that's the oldest standard 
option).  If it is invoked as "gcc", then it would reject missing 
function declarations, implicit int, etc., as hard errors.


Then these users could continue to use gcc, and their "new" compiler to 
handle their old code would be nothing more than a symbolic link.


David

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> None of these result in a whisper-level warning before a severe but
> difficult to detect breakage.

Really?  Why not run lint?

Besides, how is this any different from allowing people to write:

  extern int foo ();

or perhaps even

  extern int foo (struct bar *, long double _Complex);

when foo is something else?

> All of the features in question actively break programs (because they
> allow entirely wrong code to be emitted).

And they can also be used correctly.  GCC cannot tell the difference.
So why act as the judge, jury and executioner all rolled into one?

> It is.

It is not.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Good.  The above code is nonsense, the chances that foo will be
> incorrectly called are high.

Yet lint (or scrutiny, as should be performed with any declaration,
implicit or not) makes sure that does not happen.

> What is this meant to produce?

It was just an example.  I'm not allowed to show any real code.

> This is, at best, a "works by coincidence", rather than being code
> anyone should be writing.

See what I said about being the judge, jury and executioner.

  (BTW, I thought implicit int was being discussed, not implicit
   function declarations, but here goes.)

The same problems will appear with _any_ extern declaration.  If you
remove implicit function declarations, people will simply paste:

  extern int foo ();

above the code which no longer compiles.
Or, if you force everyone to use prototypes,

  extern int foo (char *);

You will not be able to diagnose whether or not this declaration is
correct, because the definition will lie in another translation unit.
Except that in this case, no diagnostic will be issued at all when
the declared function is called.

The only place where you can truly fix mismatched declarations is the
linker (or collect2?)  GCC proper cannot do anything about it.

> Such code is already written, when building it, pass -fpermissive.
> You benefit from the error otherwise.
>
> (and no, this isn't an issue of style, the code in question *does not*
> convey sufficient information for the compiler to always do the right
> thing)

It does on reasonable machines for which the code was written.  I gave
two examples.  Perhaps the 386 is another.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jonathan Wakely  writes:

> This is about a change in defaults. There would be options to continue
> compiling that code. It would not be banned, so the histrionics are
> unnecessary.

Please read the wording Sam used.  It clearly made reference to a ``ban''.

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Thu, 11 May 2023 at 09:32, Po Lu  wrote:
>
> Jonathan Wakely  writes:
>
> > This is about a change in defaults. There would be options to continue
> > compiling that code. It would not be banned, so the histrionics are
> > unnecessary.
>
> Please read the wording Sam used.  It clearly made reference to a ``ban''.

It's a change in defaults. It's unhelpful if you're just going to jump
into a thread in the middle and start yelling without actually
understanding what you're yelling about.

Maybe start by reading the thread subject, which says "by default".

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Thu, 11 May 2023 at 09:31, Po Lu wrote:
>   (BTW, I thought implicit int was being discussed, not implicit
>function declarations, but here goes.)

Then you're not paying attention, the very first mail in the thread
starts by saying:

TL;DR: This message is about turning implicit-int,
implicit-function-declaration, and possibly int-conversion into errors
for GCC 14.

Please educate yourself about the topic.

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu  writes:

> Arsen Arsenović  writes:
>
>> Good.  The above code is nonsense, the chances that foo will be
>> incorrectly called are high.
>
> Yet lint (or scrutiny, as should be performed with any declaration,
> implicit or not) makes sure that does not happen.

Relying on human scrutiny when an algorithm can trivially deduce an
answer more quickly and more reliably (because even in the case that the
code you showed compiles, it assumes processor specific facts) has
historic precedent as being a bad idea.

I'm curious, though, about how lint checks for this.

>> What is this meant to produce?
>
> It was just an example.  I'm not allowed to show any real code.
>
>> This is, at best, a "works by coincidence", rather than being code
>> anyone should be writing.
>
> See what I said about being the judge, jury and executioner.
>
>   (BTW, I thought implicit int was being discussed, not implicit
>function declarations, but here goes.)
>
> The same problems will appear with _any_ extern declaration.  If you
> remove implicit function declarations, people will simply paste:
>
>   extern int foo ();
>
> above the code which no longer compiles.
> Or, if you force everyone to use prototypes,
>
>   extern int foo (char *);

So be it.  The edge case still exists.  The normal case that I expect
most code is dealing with is much simpler: a missing include.  That case
is not discounted by the existence of misdeclarations across TUs.

> You will not be able to diagnose whether or not this declaration is
> correct, because the definition will lie in another translation unit.
> Except that in this case, no diagnostic will be issued at all when
> the declared function is called.
>
> The only place where you can truly fix mismatched declarations is the
> linker (or collect2?)  GCC proper cannot do anything about it.

There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
own code.

>> Such code is already written, when building it, pass -fpermissive.
>> You benefit from the error otherwise.
>>
>> (and no, this isn't an issue of style, the code in question *does not*
>> convey sufficient information for the compiler to always do the right
>> thing)
>
> It does on reasonable machines for which the code was written.  I gave
> two examples.  Perhaps the 386 is another.

Yes, indeed.  And code should keep working on those machines, because it
costs little to nothing to keep it working.  And it will if you pass
-fpermissive.

It seems to me plausible that the paragraph in the original proposal
that suggested -fpermissive might have been missed.

It is unfeasible for GCC to entirely stop compiling this code, there's
nobody that is advocating for doing that; however, the current default
of accepting this code in C is harmful to those who are writing new
code, or are learning C.

This seems like a good route to me - it facilitates both veterans
maintaining code and beginners just learning how to write C.

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Relying on human scrutiny when an algorithm can trivially deduce an
> answer more quickly and more reliably (because even in the case that the
> code you showed compiles, it assumes processor specific facts) has
> historic precedent as being a bad idea.

The algorithm in question is not much of an algorithm at all.  Rather,
it makes the blanket assumption that the lack of an explicit declaration
means the implicit declaration is incorrect, and that there is a correct
declaration in a header file somewhere.  That sounds rather premature,
don't you agree?

> I'm curious, though, about how lint checks for this.

Lint generates a lint library describing (among others) a description of
each function definition in every translation unit it checks.  It also
imports pregenerated lint libraries, such as those for the C and math
libraries.  All declarations are then checked against the lint libraries
being used.

> So be it.  The edge case still exists.  The normal case that I expect
> most code is dealing with is much simpler: a missing include.  That case
> is not discounted by the existence of misdeclarations across TUs.

I can't believe that the normal case is a missing include, because I see
`extern' declarations outside header files all the time (just look at
bash, and I believe one such declaration was just installed in Emacs.)

And how does that discount what I said people will do?  They will get
into the habit of placing:

  extern int foo ();

above each error.  Such declarations are also much more common than
implicit function declarations, and are more likely to lead to mistakes,
by the sole virtue of being 100% strictly conforming Standard C that
need not lead to any diagnostics, and thus, extra scrutiny from the
programmer.

The point is, such checks are the job of the linker and lint, because as
you yourself have observed, those are the only places where such bugs
can really be caught:

> There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
> own code.

[...]

> Yes, indeed.  And code should keep working on those machines, because it
> costs little to nothing to keep it working.  And it will if you pass
> -fpermissive.

And what prevents -fpermissive from being removed in the future, once
the folks here decide that -fpermissive must go the way of -traditional?

> It is unfeasible for GCC to entirely stop compiling this code, there's
> nobody that is advocating for doing that; however, the current default
> of accepting this code in C is harmful to those who are writing new
> code, or are learning C.

I expect people who write new code to pay even more scrutiny to
diagnostics from their C translator than usual, so the existing strategy
of issuing warnings should be sufficient.

> Have a lovely day.

You too.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jonathan Wakely  writes:

> On Thu, 11 May 2023 at 09:31, Po Lu wrote:
>>   (BTW, I thought implicit int was being discussed, not implicit
>>function declarations, but here goes.)
>
> Then you're not paying attention, the very first mail in the thread
> starts by saying:
>
> TL;DR: This message is about turning implicit-int,
   
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.

It says right there that implicit-int is being discussed.  I missed the
part about implicit function declarations.

> Please educate yourself about the topic.

Evidently (from the rest of my follow-up), I already did.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Cc: Jonathan Wakely , gcc@gcc.gnu.org
> Date: Thu, 11 May 2023 10:44:47 +0200
> From: Arsen Arsenović via Gcc 
> 
> the current default of accepting this code in C is harmful to those
> who are writing new code, or are learning C.

People who learn C should be advised to turn on all the warnings, and
should be educated not to ignore any warnings.  So this is a red
herring.

> This seems like a good route to me - it facilitates both veterans
> maintaining code and beginners just learning how to write C.

No, it prefers beginners (which already have the warnings, unless they
deliberately turn them off) to veterans who know what they are doing,
and can live with those warnings.  The right balance is exactly what
we have now: emitting warnings without breaking builds.

Re: Re: More C type errors by default for GCC 14

[Peter0x44 via Gcc]

Hi,
After reading some of this discussion, I figured I should add my own support 
for this proposal. It seems to me very few (none?) of the people arguing 
against this change actually have a "horse in the race", and instead are 
appealing to some theoretical ancient legacy code maintainer who is both too 
lazy to fix usage of these 30 year invalid constructs, or add one build option 
to CFLAGS. The very worst consequence this has to anyone is a minor irritation, 
and the benefits are definitely significant.

I find the amount of misguided arguing here to be really immense. C has enough 
"foot guns" as is, and I'm sure the improvement will be appreciated by numerous 
C beginners. I will admit I used to have the tendency of ignoring warnings when 
code appeared to function fine, as a beginner.

I don't think I'm saying anything that isn't self evident, so I'll end this by 
saying the efforts expended to argue for this change are appreciated greatly, 
by me. Along with the rest of the work occurring on the compiler. Safer and 
friendlier defaults are a goal worth pursuing.

Thanks!
Peter D.

Re: More C type errors by default for GCC 14

[James K. Lowden]

On Wed, 10 May 2023 13:00:46 +0200
David Brown via Gcc  wrote:

> or that function calls always act as a 
> memory barrier.

Hi David, [off list]

Could you tell me more about that, and where I could read about it?  

I've only been using C since 1985, so just a beginner, I guess. ;-)
As a  matter of C semantics, I can't see how a function call could be
anything but a memory barrier.  The arguments have to be resolved before
the function is called, else there's no value to provide.  And the
function has to determine its return value prior to returning.  

I can imagine in the face of multithreading that things become murky,
but that's the nature of multithreading as commonly implemented.  It's
outside C semantics.  

I'm genuinely curious what it is your referring to, in case my
understanding is out of date.  

--jkl

[wish] Flexible array members in unions

[Alejandro Colomar via Gcc]

Hi!

Currently, one can have pseudo-flexible array members in unions with
[0] syntax, but it's not allowed with [] syntax.

Here's an example of how it is possible today:

struct s {
...

size_t  n;
union {
ptrdiff_t  off[0];  // [n]; offsets from s->data.
char   data[0];
};
};

which is useful to have a structure with two (or really several)
consecutive flexible arrays: one of offsets, which mark the positions
of data, and another with the actual data.  Below goes an example
program, which works fine with GCC, and I believe rewriting it to
not use the union would make it less clear, since I'd need to add
casts to it.

It works thanks to [0] pseudo-flexible arrays, but it doesn't
compile with C99 flexible arrays.  And of course, [0] arrays have
issues with -fstrict-flex-arrays=3.


$ cat flexi4.c 
#include 
#include 
#include 
#include 

struct s {
size_t n;
union {
ptrdiff_t  off[0];
char   data[0];
};
};

int
main(void)
{
char  *p;
struct s  *s;

s = malloc(offsetof(struct s, off) +
   sizeof(ptrdiff_t) * 2 +
   sizeof("foobar") + sizeof("baz"));

s->n = 2;
p = s->data + sizeof(ptrdiff_t) * s->n;

s->off[0] = p - s->data;
p = stpcpy(p, "foobar") + 1;
s->off[1] = p - s->data;
p = stpcpy(p, "baz") + 1;

puts(s->data + s->off[0]);
puts(s->data + s->off[1]);

free(s);
}
$ gcc-13 -Wall -Wextra -Werror -fanalyzer \
 -fsanitize=undefined -fsanitize=address \
 -D_FORTIFY_SOURCE=3 -fstrict-flex-arrays=2 \
 flexi4.c 
$ ./a.out 
foobar
baz
$ gcc-13 -Wall -Wextra -Werror -fanalyzer \
 -fsanitize=undefined -fsanitize=address \
 -D_FORTIFY_SOURCE=3 -fstrict-flex-arrays=3 \
 flexi4.c 
$ ./a.out 
flexi4.c:27:8: runtime error: index 0 out of bounds for type 'ptrdiff_t [*]'
flexi4.c:29:8: runtime error: index 1 out of bounds for type 'ptrdiff_t [*]'
flexi4.c:32:23: runtime error: index 0 out of bounds for type 'ptrdiff_t [*]'
foobar
flexi4.c:33:23: runtime error: index 1 out of bounds for type 'ptrdiff_t [*]'
baz


Would you allow flexible array members in unions?  Is there any
strong reason to disallow them?

Currently, I get:

$ gcc-13 -Wall -Wextra -fanalyzer \
 -fsanitize=undefined -fsanitize=address \
 -D_FORTIFY_SOURCE=3 -fstrict-flex-arrays=3 \
 flexi4-true.c 
flexi4-true.c:9:28: error: flexible array member in union
9 | ptrdiff_t  off[];
  |^~~
flexi4-true.c:10:28: error: flexible array member in union
   10 | char   data[];
  |^~~~


Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: [wish] Flexible array members in unions

[Alejandro Colomar via Gcc]

[CC += Kees, Andrew]

[start of thread: 
]

On 5/11/23 18:07, Alejandro Colomar wrote:
> Hi!
> 
> Currently, one can have pseudo-flexible array members in unions with
> [0] syntax, but it's not allowed with [] syntax.
> 
> Here's an example of how it is possible today:
> 
> struct s {
>   ...
> 
>   size_t  n;
>   union {
>   ptrdiff_t  off[0];  // [n]; offsets from s->data.
>   char   data[0];
>   };
> };
> 
> which is useful to have a structure with two (or really several)
> consecutive flexible arrays: one of offsets, which mark the positions
> of data, and another with the actual data.  Below goes an example
> program, which works fine with GCC, and I believe rewriting it to
> not use the union would make it less clear, since I'd need to add
> casts to it.
> 
> It works thanks to [0] pseudo-flexible arrays, but it doesn't
> compile with C99 flexible arrays.  And of course, [0] arrays have
> issues with -fstrict-flex-arrays=3.
> 
> 
> $ cat flexi4.c 
> #include 
> #include 
> #include 
> #include 
> 
> struct s {
>   size_t n;
>   union {
>   ptrdiff_t  off[0];
>   char   data[0];
>   };
> };
> 
> int
> main(void)
> {
>   char  *p;
>   struct s  *s;
> 
>   s = malloc(offsetof(struct s, off) +
>  sizeof(ptrdiff_t) * 2 +
>  sizeof("foobar") + sizeof("baz"));
> 
>   s->n = 2;
>   p = s->data + sizeof(ptrdiff_t) * s->n;
> 
>   s->off[0] = p - s->data;
>   p = stpcpy(p, "foobar") + 1;
>   s->off[1] = p - s->data;
>   p = stpcpy(p, "baz") + 1;
> 
>   puts(s->data + s->off[0]);
>   puts(s->data + s->off[1]);
> 
>   free(s);
> }
> $ gcc-13 -Wall -Wextra -Werror -fanalyzer \
>  -fsanitize=undefined -fsanitize=address \
>  -D_FORTIFY_SOURCE=3 -fstrict-flex-arrays=2 \
>  flexi4.c 
> $ ./a.out 
> foobar
> baz
> $ gcc-13 -Wall -Wextra -Werror -fanalyzer \
>  -fsanitize=undefined -fsanitize=address \
>  -D_FORTIFY_SOURCE=3 -fstrict-flex-arrays=3 \
>  flexi4.c 
> $ ./a.out 
> flexi4.c:27:8: runtime error: index 0 out of bounds for type 'ptrdiff_t [*]'
> flexi4.c:29:8: runtime error: index 1 out of bounds for type 'ptrdiff_t [*]'
> flexi4.c:32:23: runtime error: index 0 out of bounds for type 'ptrdiff_t [*]'
> foobar
> flexi4.c:33:23: runtime error: index 1 out of bounds for type 'ptrdiff_t [*]'
> baz
> 
> 
> Would you allow flexible array members in unions?  Is there any
> strong reason to disallow them?
> 
> Currently, I get:
> 
> $ gcc-13 -Wall -Wextra -fanalyzer \
>  -fsanitize=undefined -fsanitize=address \
>  -D_FORTIFY_SOURCE=3 -fstrict-flex-arrays=3 \
>  flexi4-true.c 
> flexi4-true.c:9:28: error: flexible array member in union
> 9 | ptrdiff_t  off[];
>   |^~~
> flexi4-true.c:10:28: error: flexible array member in union
>10 | char   data[];
>   |^~~~
> 
> 

Currently, the Linux kernel has to go through some hoops due to this
restriction:


$ grepc -tm __DECLARE_FLEX_ARRAY *
include/uapi/linux/stddef.h:42:
#define __DECLARE_FLEX_ARRAY(TYPE, NAME)\
struct { \
struct { } __empty_ ## NAME; \
TYPE NAME[]; \
}


tools/include/uapi/linux/stddef.h:42:
#define __DECLARE_FLEX_ARRAY(TYPE, NAME)\
struct { \
struct { } __empty_ ## NAME; \
TYPE NAME[]; \
}
$ grep -rnB2 __DECLARE_FLEX_ARRAY * | head
include/uapi/rdma/rdma_user_rxe.h-153-  __u32   reserved;
include/uapi/rdma/rdma_user_rxe.h-154-  union {
include/uapi/rdma/rdma_user_rxe.h:155:  __DECLARE_FLEX_ARRAY(__u8, 
inline_data);
include/uapi/rdma/rdma_user_rxe.h:156:  __DECLARE_FLEX_ARRAY(__u8, 
atomic_wr);
include/uapi/rdma/rdma_user_rxe.h:157:  __DECLARE_FLEX_ARRAY(struct 
rxe_sge, sge);
--
include/uapi/scsi/scsi_netlink_fc.h-53- union {
include/uapi/scsi/scsi_netlink_fc.h-54- __u32 event_data;
include/uapi/scsi/scsi_netlink_fc.h:55: __DECLARE_FLEX_ARRAY(__u8, 
event_data_flex);
--




-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: More C type errors by default for GCC 14

[Jason Merrill via Gcc]

On Wed, May 10, 2023 at 7:28 PM Jonathan Wakely via Gcc  wrote:
> On Thu, 11 May 2023 at 00:18, James K. Lowden  
> wrote:
> >
> > On Tue, 9 May 2023 23:45:50 +0100
> > Jonathan Wakely via Gcc  wrote:

> Technically, the standard only requires a diagnostic, and a warning is
> a diagnostic. So strictly speaking, it's conforming to let them pass
> with a warning. The question is whether that's really the best
> behaviour for the majority of current users. At some point in the past
> it was decided that warning and continuing by default was the best
> choice. That might not still be true today.

Indeed.  We have an assortment of levels of diagnostic.

error: always causes compilation to fail
   These are constructs for which either there's no reasonable
interpretation or no perceived benefit to accepting the code.

permerror: causes compilation to fail without -fpermissive
   Ill-formed constructs that we want to prevent in new code, but want
to allow in legacy code.

pedwarn on by default: warning by default, error with -pedantic-errors
   Ill-formed constructs that we think new code shouldn't use but are
ok to allow with a warning.

conditional pedwarn: warning with -pedantic, error with -pedantic-errors
   Ill-formed constructs that we support as an extension.

warnings on by default
  Patterns that are well-formed but almost certainly a mistake.

warnings in -Wall
  Patterns that are very likely a mistake.

warnings in -Wextra
  Patterns that are likely a mistake.

warnings you have to enable specifically
  Patterns that you want help to avoid.

Particular diagnostics can move between categories as perceptions
change over time.  My understanding of the proposal is that it
proposes to move these particular diagnostics from category 3 up to
category 2, both because code that relies on these patterns has gotten
less common and using these patterns by mistake has gotten more
harmful.

Jason

Re: [wish] Flexible array members in unions

[Kees Cook via Gcc]

On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> On 5/11/23 18:07, Alejandro Colomar wrote:
> [...]
> > Would you allow flexible array members in unions?  Is there any
> > strong reason to disallow them?

Yes please!! And alone in a struct, too.

AFAICT, there is no mechanical/architectural reason to disallow them
(especially since they _can_ be constructed with some fancy tricks,
and they behave as expected.) My understanding is that it's disallowed
due to an overly strict reading of the very terse language that created
flexible arrays in C99.

> [...]
> Currently, the Linux kernel has to go through some hoops due to this
> restriction:
> 
> 
> $ grepc -tm __DECLARE_FLEX_ARRAY *
> include/uapi/linux/stddef.h:42:
> #define __DECLARE_FLEX_ARRAY(TYPE, NAME)  \
>   struct { \
>   struct { } __empty_ ## NAME; \
>   TYPE NAME[]; \
>   }

Yes, we've had to do this as we eradicate all the fake flexible arrays
in the kernel which cause endless bugs[1]. Additionally, we'll be
using -fstrict-flex-arrays=3 soon to let existing array bounds checking
mitigations gain coverage over trailing arrays. All of this means that
we're converting a lot of code that is happily using dynamically sized
arrays in unions, etc.

[1] https://people.kernel.org/kees/bounded-flexible-arrays-in-c

-- 
Kees Cook

Re: [wish] Flexible array members in unions

[Joseph Myers]

On Thu, 11 May 2023, Kees Cook via Gcc wrote:

> On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > On 5/11/23 18:07, Alejandro Colomar wrote:
> > [...]
> > > Would you allow flexible array members in unions?  Is there any
> > > strong reason to disallow them?
> 
> Yes please!! And alone in a struct, too.
> 
> AFAICT, there is no mechanical/architectural reason to disallow them
> (especially since they _can_ be constructed with some fancy tricks,
> and they behave as expected.) My understanding is that it's disallowed
> due to an overly strict reading of the very terse language that created
> flexible arrays in C99.

Standard C has no such thing as a zero-size object or type, which would 
lead to problems with a struct or union that only contains a flexible 
array member there.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Eli Zaretskii  writes:

>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Thu, 11 May 2023 10:44:47 +0200
>> From: Arsen Arsenović via Gcc 
>> 
>> the current default of accepting this code in C is harmful to those
>> who are writing new code, or are learning C.
>
> People who learn C should be advised to turn on all the warnings, and
> should be educated not to ignore any warnings.  So this is a red
> herring.

Indeed they should be - but warning vs. error holds significance.  A
beginner is much less likely to be writing clever code that allegedly
uses these features properly than to be building new code, and simply
having made an error that they do not want and will suffer through
confused.

>> This seems like a good route to me - it facilitates both veterans
>> maintaining code and beginners just learning how to write C.
>
> No, it prefers beginners (which already have the warnings, unless they
> deliberately turn them off) to veterans who know what they are doing,
> and can live with those warnings.

Indeed.  I said facilitates, not treats equally.  I think the veterans
here won't lose much by having to pass -fpermissive, and I think that's
a worthwhile sacrifice to make, to nurture the new without pressuring
the old very much.

> The right balance is exactly what we have now: emitting warnings
> without breaking builds.

I disagree - I think breaking builds here (remember, it takes 13 bytes
to fix them) is a much lower weight than the other case being shot in
the foot for an easily detectable and treatable error being made easily
missable instead, so I reckon the scale is tipped heavily towards the
veterans.

On that note - lets presume a beginners role.  I've just started using
GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
mentions some 'implicit function generation', dunno what that means - if
it mattered much, it'd have been an error.  I wrote a function called
test that prints the int it got in hex, but I called it with 12.3, but
it printed 1.. what the heck?

Why that happened is obvious to you and I (if you're on the same CPU as
me), but to a beginner is utter nonsense.

At this point, I can only assume one goes to revisit that warning..  I'd
hope so at least.

I doubt the beginner would know to pass
-Werror=implicit-function-declaration in this case (or even about
Werror...  I just told them what -Wall and to read the warnings, which
was gleefully ignored)

Anyway - I'm not making that up - this circle of 'yeah the warnings
actually matter.. a lot' has happened with everyone I've tutored that
has had little to no contact with programming before (those who had more
contact have a higher respect for the word 'warning'), and it will keep
happening.

Hell, I've seen professors do it, and for a simple reason: they knew how
to write code, not how to use a compiler.  That's a big gap.

The beginner here can't adapt - they don't know what -Wall means, they
just pass it because they were told to do it (if they're lucky!).

At the same time, they lose out on what is, IMO, one of the most useful
pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
it by default.. we do).  It provides effective bug detection, when the
code compiles right.  It regularly spots bugs that haven't happened yet
for me.

(and same goes for all the other useful analysis the toolchain can do
when it has sufficient information to generate correct code, or more;
some of which can't reasonably be a default)

(on a related note, IMO it's a shame that the toolchain hides so many
possibilities behind 'cult knowledge', depths of many manuals and bad
defaults)

On the other hand... I've been writing C for a long time, and you have
been doing so for a longer time.  We see 'error: ...' in an old codebase
for a pedantic (rather, by my definition, bare essential) check and we
know where to look to fix it or ignore it.

I build old, unfamiliar codebases all the time, and I've been using a
modified toolchain that enables the error proposed today for a while; my
peers and I, who are proposing this, have gone over thousands of old
codebases, I've fixed some personally, yet the percentage of those that
have been full-out broken by this change is small (configure scripts are
almost all of it, too; Po has mentioned that they use a laxer compiler
for those - we (Gentoo) test two compilers in order to detect when these
differences happen, but keep the results of the laxer one, and then try
to fix the code upstream - often it comes down to just running autoconf
-f, even).

This sample is subject to selection bias.  My testing targets mostly
more modern codebases that have long fixed these errors (if they have
active maintainers), and exclusively Free Software, so I expect that the
likelyhood that you'll need to run `export CC='gcc -fpermissive'
CXX='g++ -fpermissive'` goes up the more you move towards old or more
corporate codebases, but, for a veteran, this is no cost at all.

Is it that much of a stretch to imagin

Re: [wish] Flexible array members in unions

[Kees Cook via Gcc]

On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> 
> > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > On 5/11/23 18:07, Alejandro Colomar wrote:
> > > [...]
> > > > Would you allow flexible array members in unions?  Is there any
> > > > strong reason to disallow them?
> > 
> > Yes please!! And alone in a struct, too.
> > 
> > AFAICT, there is no mechanical/architectural reason to disallow them
> > (especially since they _can_ be constructed with some fancy tricks,
> > and they behave as expected.) My understanding is that it's disallowed
> > due to an overly strict reading of the very terse language that created
> > flexible arrays in C99.
> 
> Standard C has no such thing as a zero-size object or type, which would 
> lead to problems with a struct or union that only contains a flexible 
> array member there.

Ah-ha, okay. That root cause makes sense now.

Why are zero-sized objects missing in Standard C? Or, perhaps, the better
question is: what's needed to support the idea of a zero-sized object?

-- 
Kees Cook

Re: More C type errors by default for GCC 14

[Segher Boessenkool]

Hi Florian,

On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote:
> * alleged code generation bugs because the upper 32 bits of a pointer
>   are set to zero or 0x, resulting in crashes.  This can happen
>   if GCC synthesizes an implicit int declaration for a pointer-returning
>   function.
> 
> * Alleged code generation bugs because a function returning bool does
>   not set the entire register, as expected the caller.  This can happen
>   if GCC makes up a function declaration returning int for a function
>   that actually returns bool on x86-64.

Both of these cannot happen with better ABIs, by design.  Of course
every ABI has its own idiosyncrasies :-)

> I hope this makes things clearer.  I do think the current GCC defaults
> are needlessly frustrating, which is why I spent so much time on proving
> (from my perspective) that it should be feasible to change them.

Yes, I agree with this sentiment, and I think we can do a lot better
than we do now.

> We can get fairly close by injecting appropriate -Werror= options during

As you know, IMNSHO the only appropriate subset of -Werror= options is
the empty subset.

-Werror is for the user (the USER, not the build system) to ask "yes
please, I have all my priorities upside down, do fail compiling anything
that may look unexpected".  Most warnings are *heuristic*.  Other
warnings are for code that does not follow (modern) best practices.

But (most of) the diagnostics you propose to upgrade from warnings to
errors are not like this at all: they point out definite flaws, things
that just are not correct C code at all, and never were for that matter.
We always warn for those (without -Wall even) already, so upgrading
these to errors is a no-brainer really, as long as we also get
-fpermissive!


Segher

Re: [wish] Flexible array members in unions

[Joseph Myers]

On Thu, 11 May 2023, Kees Cook via Gcc wrote:

> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> question is: what's needed to support the idea of a zero-sized object?

Zero-sized objects break the principle that different objects have 
different addresses, and the principle of being able to subtract pointers 
to different elements of an array.  There would also be serious C++ 
compatibility concerns, since C++ allows a struct with no members but it 
has nonzero size, unlike the GNU C extension where a struct with no 
members has size zero.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [wish] Flexible array members in unions

[Kees Cook via Gcc]

On Thu, May 11, 2023 at 09:43:49PM +, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> 
> > Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> > question is: what's needed to support the idea of a zero-sized object?
> 
> Zero-sized objects break the principle that different objects have 
> different addresses, and the principle of being able to subtract pointers 
> to different elements of an array.  There would also be serious C++ 
> compatibility concerns, since C++ allows a struct with no members but it 
> has nonzero size, unlike the GNU C extension where a struct with no 
> members has size zero.

Okay, understood. If this is a C-only thing, we can ignore the C++
impact. What depends on the "different objects have different addresses"
principle? And why do unions not break this -- they could point to the
same locations within the object? And don't flexible arrays already need
special handling in this regard?

-- 
Kees Cook

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>> Date: Wed, 10 May 2023 23:14:20 -0400
>> From: Eli Schwartz via Gcc 
>>
>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
> 
> He is telling you that removing support for these old features, you
> draw users away from GCC and towards proprietary compilers.
> 
> One of the arguments in this thread _for_ dropping that support was
> that by not rejecting those old programs, GCC draws some users away
> from GCC.  He is telling you that this change will, perhaps, draw some
> people to GCC, but will draw others away from GCC.  The difference is
> that the former group will start using Clang, which is still free
> software (at least some of its versions), whereas the latter group has
> nowhere to go but to proprietary compilers.  So the FOSS community
> will have suffered a net loss.  Something to consider, I think.


Except this thread is not arguing to remove support for -std=c89 as far
as I can tell?

The argument is that on newer values for -std (such as the one GCC
defaults to if no -std is specified), GCC should adapt its diagnostics
better for the std in question. These newer -stds should stop issuing a
warning diagnostic, and begin issuing an error diagnostic instead.

The latter group most certainly does have somewhere to go other than
proprietary compilers -- it can go to GCC with -std=c89 (or -Wno-* or
-fpermissive or -fold-code or whatever the case may be).

But I do not understand the comparison to -traditional. Which was
already removed, and already resulted in, apparently, at least one group
being so adamant on not-C that it switched to a proprietary compiler.
Okay, understood. But at this point that group is no longer users of
GCC... right?

So what is the moral of this story? To avoid repeating the story of
-traditional, and instead make sure that users of -std=c89 always have a
flag they can use to indicate they are writing old c89 code?

If so, then as far as I can tell, that was the original plan? The flag
already exists, even. And the original proposal was to provide another
flag that doesn't even restrict you to c89.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Schwartz via Gcc  writes:

> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>>> Date: Wed, 10 May 2023 23:14:20 -0400
>>> From: Eli Schwartz via Gcc 
>>>
>>> Second of all, why is this GCC's problem? You are not a user of GCC,
>>> apparently.
>> 
>> He is telling you that removing support for these old features, you
>> draw users away from GCC and towards proprietary compilers.
>> 
>> One of the arguments in this thread _for_ dropping that support was
>> that by not rejecting those old programs, GCC draws some users away
>> from GCC.  He is telling you that this change will, perhaps, draw some
>> people to GCC, but will draw others away from GCC.  The difference is
>> that the former group will start using Clang, which is still free
>> software (at least some of its versions), whereas the latter group has
>> nowhere to go but to proprietary compilers.  So the FOSS community
>> will have suffered a net loss.  Something to consider, I think.
>
>
> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>

And I would not want to see that happen either, nor do I think Florian
would, or many of the other participants in this thread.

Indeed, for some projects, where it's hopeless^Wlots of work,
we're using -std=c89 or -std=gnu89 as appropriate - as already stated.

But most things are easy to fix.

Our interest is purely in making the default stricter for better UX,
reducing the net amount of these bugs in the wild, and avoiding
regressions when we fix these problems. Trying to remove C89 entirely
would, if nothing else, be needlessly antagonistic, but some of the
replies seem to act as if we have.



signature.asc
Description: PGP signature

gcc-11-20230511 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230511 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230511/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 173216f75b5b73f02cb414165ea6e6b0535d9fe5

You'll find:

 gcc-11-20230511.tar.xz   Complete GCC

  SHA256=0f5c7f109b285c69f56bad975a7f7279ef16c65a5a2fe47f7957e6f5e8491beb
  SHA1=ecf34aab423b6d908f66d2d6463d61c6a4eb6606

Diffs from 11-20230504 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 2:18 AM, Po Lu wrote:
> Eli Schwartz  writes:
>> 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.


I expect no such thing, but I do expect that people making decisions in
the real world acknowledge that ***they*** (and no one else) made those
decisions of their own volition.

I am unsure what "decisions made in the real world" has to do with my
observation that this real-world decision was a decision to invest time
and effort and money in one direction rather than another direction --
and the rejected other direction was the one that would make them users
of GCC who are affected by GCC decisions.


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


I do not consider that you are being told what to do with your code.
Your code is not being broken. You may have to update your Makefile to
add a flag that turns off a changed default, but that does not
constitute being told what to do with your code, only being told what to
do with GCC.


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


Very well then, (lots of) C++ is C.

But many people do in fact argue that missing function declarations do
not, in fact, look like C. It doesn't compile in a C compiler (using
-Werror) either. Some of the warnings under discussion in this thread
were never valid *anywhere*.


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


Some people like writing some code in one language version, and some
code in another language version, and doing so in the same file or
perhaps even the same function. Acknowledged. I would personally be
afraid to do that, it seems incredibly dangerous even if in the highly
specific case of implicit function declarations it happened to work.

Because that's exactly what is going on here. Features that were valid
C89 code are being used in a GNU99 or GNU11 code file, despite that
***not*** bein

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> Please be serious, and please don't mock your opponents.  This is a
> serious discussion of a serious subject, not a Twitter post.


I responded with precisely the degree of seriousness as the statement I
responded to.

For the record, I believe both statements to have been serious. Not
necessarily correct, but serious.


> Back to the subject: the guarantees I would personally like to have is
> that the current GCC development team sees backward compatibility as
> an important goal, and will try not to break old programs without very
> good technical reasons.  At least in Emacs development, that is the
> consideration that is very high on our priority list when making
> development decisions.  It would be nice if GCC (and any other GNU
> project, for that matter) would do the same, because being able to
> upgrade important tools and packages without fear is something users
> value very much.  Take it from someone who uses GCC on various
> platforms since version 1.40.


This discussion thread is about having very good technical reasons -- as
explained multiple times, including instances where you agreed that the
technical reasons were good.

Furthermore, even despite those technical reasons, GCC is *still*
committed to not breaking those old programs anyway. GCC merely wants to
make those old programs have to be compiled in an "old-programs" mode.

Can you explain to me how you think this goal conflicts with your goal?


-- 
Eli Schwartz

Re: [wish] Flexible array members in unions

[Joseph Myers]

On Thu, 11 May 2023, Kees Cook via Gcc wrote:

> Okay, understood. If this is a C-only thing, we can ignore the C++
> impact.

We're a lot more careful lately in WG14 about checking for C++ 
compatibility issues and expecting approval from the liaison group for 
anything with possible compatibility concerns for syntax in the common 
subset of C and C++.  So, no, we can't ignore the C++ impact for adding 
empty types; it would need careful consideration in the liaison group.

> What depends on the "different objects have different addresses"
> principle? And why do unions not break this -- they could point to the
> same locations within the object? And don't flexible arrays already need
> special handling in this regard?

"including a pointer to an object and a subobject at its beginning" and 
"one is a pointer to one past the end of one array object and the other is 
a pointer to the start of a different array object that happens to 
immediately follow the first array object in the address space" are both 
cases included in the semantics for comparison operators.  If you allow 
zero-size objects you get more special cases there (and quite possibly 
affect optimizations based on points-to analysis that can determine 
pointers are based on different objects, if an object is not known at 
compile time to have nonzero size).

-- 
Joseph S. Myers
jos...@codesourcery.com

Wish: scoped enum

[Yair Lenga via Gcc]

Hi,

I wonder if it will be possible to add support for "scoped" enum to GCC.
The current C standard has one name space for all enums, and different name
space for the members of each "struct". As a result, possible to say

struct foo { int a } ;
struct bar { double a }; // This is different 'a', different type

But illegal to to (ignoring the conversion to use all upper for enum).

enum a { u, v } ;
enum b { v, w } ; // can not do this, as 'v' must be distinct

One annoying side effect is that any package/module creating an enum has to
worry about namespace collision with everyone else in the world. Common
practices include distinct prefixes, similar to the way different libraries
use distinct prefixes to avoid function name collision. This solution is
far from perfect and leads to excessive long enum name.

A reasonable wish list - add a magic keyword that will place the enums into
a scope, so that the following work:

SCOPED enum shirt_sz { small, medium, large } ;
SCOPED enum shoe_sz { small, medium, medium_wide, large, xlarge } ;

enum shirt_sz tshift_size = shift_sz.medium ;
enum shoe_siz boot_size = shoe_sz.xlarge ;

Not perfect, but not complex, will make enum reusable across many scenario,
where they are currently hard to implement - because of namespace conflict
- between system header and user headers, between different packages.

A smart compiler can also alert when "types" are mixed (assign value from
shift_sz to a variable of type shoe_sz). Not critical - as my understanding
is that this is not enforced today. For the case that an enum symbol is
distinct (in the current compilation unit), the compiler can allow using it
without the namespace - practically falling back into current behavior.

Feedback ? Anyone know how to get a prototype into gcc ? How one get
approval for such "extensions".

Yair

Re: Wish: scoped enum

[Arsen Arsenović via Gcc]

Hi,

Yair Lenga via Gcc  writes:

> I wonder if it will be possible to add support for "scoped" enum to GCC.
> The current C standard has one name space for all enums, and different name
> space for the members of each "struct". As a result, possible to say
>
> struct foo { int a } ;
> struct bar { double a }; // This is different 'a', different type
>
> But illegal to to (ignoring the conversion to use all upper for enum).
>
> enum a { u, v } ;
> enum b { v, w } ; // can not do this, as 'v' must be distinct
>
> One annoying side effect is that any package/module creating an enum has to
> worry about namespace collision with everyone else in the world. Common
> practices include distinct prefixes, similar to the way different libraries
> use distinct prefixes to avoid function name collision. This solution is
> far from perfect and leads to excessive long enum name.
>
> A reasonable wish list - add a magic keyword that will place the enums into
> a scope, so that the following work:
>
> SCOPED enum shirt_sz { small, medium, large } ;
> SCOPED enum shoe_sz { small, medium, medium_wide, large, xlarge } ;
>
> enum shirt_sz tshift_size = shift_sz.medium ;
> enum shoe_siz boot_size = shoe_sz.xlarge ;
>
> Not perfect, but not complex, will make enum reusable across many scenario,
> where they are currently hard to implement - because of namespace conflict
> - between system header and user headers, between different packages.
>
> A smart compiler can also alert when "types" are mixed (assign value from
> shift_sz to a variable of type shoe_sz). Not critical - as my understanding
> is that this is not enforced today. For the case that an enum symbol is
> distinct (in the current compilation unit), the compiler can allow using it
> without the namespace - practically falling back into current behavior.
>
> Feedback ? Anyone know how to get a prototype into gcc ? How one get
> approval for such "extensions".

I'd suggest, if you choose to implement this, to imitate what C++ does
for these, maybe even propose it for the standard.  There's already
established syntax and semantics.

It would certainly be nice to have such a thing in C.

Have a lovely evening.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Wish: scoped enum

[Gabriel Ravier via Gcc]

On 5/12/23 01:58, Yair Lenga via Gcc wrote:

Hi,

I wonder if it will be possible to add support for "scoped" enum to GCC.
The current C standard has one name space for all enums, and different name
space for the members of each "struct". As a result, possible to say

struct foo { int a } ;
struct bar { double a }; // This is different 'a', different type

But illegal to to (ignoring the conversion to use all upper for enum).

enum a { u, v } ;
enum b { v, w } ; // can not do this, as 'v' must be distinct

One annoying side effect is that any package/module creating an enum has to
worry about namespace collision with everyone else in the world. Common
practices include distinct prefixes, similar to the way different libraries
use distinct prefixes to avoid function name collision. This solution is
far from perfect and leads to excessive long enum name.

A reasonable wish list - add a magic keyword that will place the enums into
a scope, so that the following work:

SCOPED enum shirt_sz { small, medium, large } ;
SCOPED enum shoe_sz { small, medium, medium_wide, large, xlarge } ;

enum shirt_sz tshift_size = shift_sz.medium ;
enum shoe_siz boot_size = shoe_sz.xlarge ;

Not perfect, but not complex, will make enum reusable across many scenario,
where they are currently hard to implement - because of namespace conflict
- between system header and user headers, between different packages.

A smart compiler can also alert when "types" are mixed (assign value from
shift_sz to a variable of type shoe_sz). Not critical - as my understanding
is that this is not enforced today. For the case that an enum symbol is
distinct (in the current compilation unit), the compiler can allow using it
without the namespace - practically falling back into current behavior.

Feedback ? Anyone know how to get a prototype into gcc ? How one get
approval for such "extensions".

Yair


You may wish to learn about 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf - 
although of course this isn't available in C right now, but the addition 
of a differing, syntactically incompatible while substantially 
overlapping feature to C to reproduce the same functionality as `enum 
class` seems far more unlikely to occur than the addition of `enum 
class` to C.

Re: [wish] Flexible array members in unions

[Alejandro Colomar via Gcc]

Hi Joseph, Kees,

On 5/12/23 00:52, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> 
>> Okay, understood. If this is a C-only thing, we can ignore the C++
>> impact.
> 
> We're a lot more careful lately in WG14 about checking for C++ 
> compatibility issues and expecting approval from the liaison group for 
> anything with possible compatibility concerns for syntax in the common 
> subset of C and C++.  So, no, we can't ignore the C++ impact for adding 
> empty types; it would need careful consideration in the liaison group.
> 
>> What depends on the "different objects have different addresses"
>> principle? And why do unions not break this -- they could point to the
>> same locations within the object? And don't flexible arrays already need
>> special handling in this regard?
> 
> "including a pointer to an object and a subobject at its beginning" and 
> "one is a pointer to one past the end of one array object and the other is 
> a pointer to the start of a different array object that happens to 
> immediately follow the first array object in the address space" are both 
> cases included in the semantics for comparison operators.  If you allow 
> zero-size objects you get more special cases there (and quite possibly 
> affect optimizations based on points-to analysis that can determine 
> pointers are based on different objects, if an object is not known at 
> compile time to have nonzero size).

Since GNU C already supports empty structs, how about allowing that in GCC
with no intention of adding it to ISO C?  We'll see how good it behaves in
GCC, and if so suggest it for inclusion in the standard.

Why should GNU C, which allows empty structures, and de facto supports
flexible arrays in empty structs and in unions (via the empty preceeding
struct and the wrapper struct tricks, as the kernel does), shouldn't
support them officially without tricks?

Apart from violating artificial rules that disallow that use of flexible
arrays, I believe the example program I provided in the first post
doesn't violate aliasing rules or other similar rules that would result
in optimization conflicts.  Does it?

About zero-sized types, a union consisting of only flexible-array members
would effectively be a zero-sized type, so GCC should have similar issues
having this in unions and in empty structs.  So far, I don't see GCC
complaining about such horrible thing as an array of empty structs:

$ cat arr.c
#include 

struct s {};

struct s x[10];

int
main(void)
{
printf("x:%zu, %p\n", sizeof(x), &x);
printf("x[3]: %zu, %p\n", sizeof(x[3]), &x[3]);
}
$ gcc-13 arr.c -Wall -Wextra
$ ./a.out 
x:0, 0x55c5f6d72019
x[3]: 0, 0x55c5f6d72019



So, in GNU C land, I think it is reasonable to add this feature.

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Seems that the algorithm and I agree.  I don't see any use in the int()
> guess that the compiler does, besides accepting old code (which makes it
> candidate for -fpermissive).

I believe:

  extern int foo ();

covers at least 50% of all C functions, since they are generally defined
to return int (as an error indication) with no narrow types in any
prototyped parameter list.  That's a reasonable enough guess.

> We can diagnose these without invoking expensive machinery, unlike
> mismatched declarations.

How so?  Remember that `extern int foo ()' declares a function with no
parameter specification returning int.

Thus, it could mean either:

  foo (a, b)
  char *a;
  long b;

or

  foo (x, y)
  double x;
  double y;

or perhaps even

  foo (va_alist)
  va_dcl

The function may even be defined with a prototyped parameter list, as
long as said parameter list does not contain any narrow types which are
subject to default argument promotions.

> I don't see why these not being diagnosed by default makes erroring on
> the far simpler implicit case not valuable (even if it leads to people
> just consciously inserting wrong declarations - that means they
> acknowledged it and made a poor decision).

All this will lead to is people making what you deem to be a ``poor''
decision.  Especially if the people who have to solve the build problems
are not the original author(s) of the program being built.

> They can be caught in multiple places when obvious, such as when not
> done explicitly.  These are two different errors.

An implicit function declaration is NOT an obvious error.  It simply may
be an error.  What is the error here?

a (b, c)
long c;
{
  return pokeaddr (c, b * FOO);
}

/* in another translation unit */

b ()
{
  a (1, 0L);
}

GCC is not a judge of other people's code, and shouldn't try to be one.

> I can't say.  I don't have memory of the traditional mode outside of
> cpp.

-traditional tried to make GCC a K&R compiler.  It wasn't completely
K&R, but it worked well enough for most cases.  There,

  - `extern' definitions take effect even outside the scope in which
they are declared.
  - typeof, inline, signed, const and volatile are not recognized.
  - unsigned narrow types promote to unsigned int.
  - string constants are always writable.  (BTW, -fwritable-strings
was also removed, so you can see why I'm sceptical about
any commitment to `-fpermissive' if it is ever introduced.)
  - register allocation is not performed within functions that call
setjmp.
  - bit-fields are always unsigned.
  - single precision floating point arithmetic is carried out in
double precision.
  - __STDC__ is not defined.

> The changes proposed today, however, are a few bits of entropy
> relevant in a few places - the overhead is low.

Yet it's rather pointless, as I explained above.

> It's not, though.  That's why this is being conversed about.  Even
> highly diligent people miss these (and even not-so-diligent people like
> me do - I've had more of these found by me passing -flto than I did by
> remembering to use an extra four -Werror=... flags, and that, of course,
> misses the int(...) case - which is not a useful one, usually what I
> meant there was (void), but strict-prototypes are a story for another
> day or year).

I can't say I've seen any such errors myself.  Perhaps people should be
told to run lint instead, whose sole job is to prevent these errors from
happening?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> I expect no such thing, but I do expect that people making decisions in
> the real world acknowledge that ***they*** (and no one else) made those
> decisions of their own volition.
>
> I am unsure what "decisions made in the real world" has to do with my
> observation that this real-world decision was a decision to invest time
> and effort and money in one direction rather than another direction --
> and the rejected other direction was the one that would make them users
> of GCC who are affected by GCC decisions.

The point is, we chose not to modify GCC for various reasons, and the
changes being proposed here will cause more people to make this choice.

> I do not consider that you are being told what to do with your code.
> Your code is not being broken. You may have to update your Makefile to
 

My code is being broken.  There are thousands of Makefiles, Autoconf
files containing configure tests, and so on.

> add a flag that turns off a changed default, but that does not
> constitute being told what to do with your code, only being told what to
> do with GCC.

That's GCC trying to tell me what to do with my own code.

> Very well then, (lots of) C++ is C.
>
> But many people do in fact argue that missing function declarations do
> not, in fact, look like C. It doesn't compile in a C compiler (using
 ^^

% cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31
% cc -Xs -Werror hello.c -o hello
% ./hello
hello world
the time is: 1683856188
% cat hello.c

struct timeval
{
  long tv_sec;
  long tv_usec;
};

main ()
{
  struct timeval tv;

  printf ("hello world\n");
  if (gettimeofday (&tv, 0L))
exit (1);
  printf ("the time is: %ld\n", tv.tv_sec);
}

% 

> -Werror) either. Some of the warnings under discussion in this thread
> were never valid *anywhere*.

Really? Is that, or is that not, a C compiler?

> Some people like writing some code in one language version, and some
> code in another language version, and doing so in the same file or
> perhaps even the same function. Acknowledged. I would personally be
> afraid to do that, it seems incredibly dangerous even if in the highly
> specific case of implicit function declarations it happened to work.
>
> Because that's exactly what is going on here. Features that were valid
> C89 code are being used in a GNU99 or GNU11 code file, despite that
> ***not*** being valid GNU99 or GNU11 code.

How GCC currently behaves defines what is valid GNU C.

> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
> make it a GNU extension. It compiles with a warning in c11 mode too,
> does that make it a c11 extension? No it does not.

Except it does?  Since the compiler is defining behavior that is
otherwise undefined (i.e. the behavior of a program after a diagnostic
is emitted after encountering an erroneous construct), it is defining
an extension.

> I am not dictating anything to you or anyone else in this paragraph,
> though? All I said was that if one writes a c89 program and tells the
> compiler that, then they will not even notice this entire discussion to
> begin with.
>
> What, precisely, have I dictated?

That people who are writing GNU C code should be forced to rewrite their
code in ANSI C, in order to make use of GNU C extensions to the 1999
Standard.

> Have I dictated to you that a c89 program can be described to the
> compiler by use of the -std=c89 flag? This seems to be a pretty standard
> understanding, to me.

No, see above.

> Correction: I am arguing by analogy that your statement: "what
> guarantees that -Wno-implicit will not be removed in the future" is
> arguing to absurdity.

The reason I asked for such a guarantee was that two important options
were in fact removed by the GCC developers in the past: -traditional and
-fwritable-strings.  So there is not exactly a good track record of
keeping useful options around, after features are made into those
arguments.

> Many people write strictly conforming program, and consider lack of
> conformance to be a coding error that must be fixed. It seems like a
> wise endeavor, frankly. I am not sure why you are challenging me to do
> so as though you think that I will be incapable of it and therefore be
> forced to concede that toggling the default diagnostic for very old code
> is a bad idea.

Really? So how many programs work when int is 16, 36, or 40 bits wide?
How many programs work when signed char has trap representations?
How many programs when char not 8 bits?

How many programs assume pointers can be converted into an integer type
without any loss of information?  How many programs assume that
pointers have only one possible integer representation?  (think lookup
tables using pointers to objects as keys)

How many programs assume NULL is all-bits-zero?  IOW, that this
initialization makes sense:

struct foo
{
  void *ptr;

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Indeed they should be - but warning vs. error holds significance.  A
> beginner is much less likely to be writing clever code that allegedly
> uses these features properly than to be building new code, and simply
> having made an error that they do not want and will suffer through
> confused.

Most programs already paste a chunk of Autoconf into their configure.ins
which turns on more diagnostics if it looks like the program is being
built by a developer.  i.e. from Emacs:

AC_ARG_ENABLE([gcc-warnings],
  [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@],
  [control generation of GCC warnings.  The TYPE 'yes'
   means to fail if any warnings are issued; 'warn-only'
   means issue warnings without failing (default for
   developer builds); 'no' means disable warnings
   (default for non-developer builds).])],
  [case $enableval in
 yes|no|warn-only) ;;
 *)  AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
   esac
   gl_gcc_warnings=$enableval],
  [# By default, use 'warn-only' if it looks like the invoker of 'configure'
   # is a developer as opposed to a builder.  This is most likely true
   # if GCC is recent enough and there is a .git directory or file;
   # however, if there is also a .tarball-version file it is probably
   # just a release imported into Git for patch management.
   gl_gcc_warnings=no
   if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
  # Clang typically identifies itself as GCC 4.2 or something similar
  # even if it is recent enough to accept the warnings we enable.
  AS_IF([test "$emacs_cv_clang" = yes],
 [gl_gcc_warnings=warn-only],
 [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])])
   fi])

So this is really not a problem.

> Indeed.  I said facilitates, not treats equally.  I think the veterans
> here won't lose much by having to pass -fpermissive, and I think that's
> a worthwhile sacrifice to make, to nurture the new without pressuring
> the old very much.

Until `-fpermissive' goes the way of `-traditional',
`-fwritable-strings'.

> On that note - lets presume a beginners role.  I've just started using
> GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
> mentions some 'implicit function generation', dunno what that means - if
> it mattered much, it'd have been an error.  I wrote a function called
> test that prints the int it got in hex, but I called it with 12.3, but
> it printed 1.. what the heck?

Have you actually seen anyone make this mistake?

> Why that happened is obvious to you and I (if you're on the same CPU as
> me), but to a beginner is utter nonsense.
>
> At this point, I can only assume one goes to revisit that warning..  I'd
> hope so at least.
>
> I doubt the beginner would know to pass
> -Werror=implicit-function-declaration in this case (or even about
> Werror...  I just told them what -Wall and to read the warnings, which
> was gleefully ignored)

I'd expect a question from the newbie, directed at a web search engine.

> Hell, I've seen professors do it, and for a simple reason: they knew how
> to write code, not how to use a compiler.  That's a big gap.
>
> The beginner here can't adapt - they don't know what -Wall means, they
> just pass it because they were told to do it (if they're lucky!).

If this is really such a bad problem, then how about clarifying the
error message?

> At the same time, they lose out on what is, IMO, one of the most useful
> pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
> it by default.. we do).  It provides effective bug detection, when the
> code compiles right.  It regularly spots bugs that haven't happened yet
> for me.
>
> (and same goes for all the other useful analysis the toolchain can do
> when it has sufficient information to generate correct code, or more;
> some of which can't reasonably be a default)
>
> (on a related note, IMO it's a shame that the toolchain hides so many
> possibilities behind 'cult knowledge', depths of many manuals and bad
> defaults)

_FORTIFY_SOURCE is not really important enough to be considered here.
It's not even available everywhere.

> This sample is subject to selection bias.  My testing targets mostly
> more modern codebases that have long fixed these errors (if they have
> active maintainers), and exclusively Free Software, so I expect that the
> likelyhood that you'll need to run `export CC='gcc -fpermissive'
> CXX='g++ -fpermissive'` goes up the more you move towards old or more
> corporate codebases, but, for a veteran, this is no cost at all.
>
> Is it that much of a stretch to imagine that a maintainer of a codebase
> that has not seen revisions to get it past K&R-esque practices would
> know that they need to pass -std=c89 (or a variant of such), or even
> -fpermissive - assuming that they could even spare to use GCC 14 as
> opposed to 2.95?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.
>
> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not breaking those old programs anyway. GCC merely wants to
> make those old programs have to be compiled in an "old-programs" mode.
>
> Can you explain to me how you think this goal conflicts with your goal?

Because now people will have to go through dozens and dozens of
Makefiles, configure.in, *.m4, just because GCC made a decision that
results in everyone inserting:

  extern int foo ();

above what used to be implicit function declarations?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>
> The argument is that on newer values for -std (such as the one GCC
> defaults to if no -std is specified), GCC should adapt its diagnostics
> better for the std in question. These newer -stds should stop issuing a
> warning diagnostic, and begin issuing an error diagnostic instead.
>
> The latter group most certainly does have somewhere to go other than
> proprietary compilers -- it can go to GCC with -std=c89 (or -Wno-* or
> -fpermissive or -fold-code or whatever the case may be).
>
> But I do not understand the comparison to -traditional. Which was
> already removed, and already resulted in, apparently, at least one group
> being so adamant on not-C that it switched to a proprietary compiler.
> Okay, understood. But at this point that group is no longer users of
> GCC... right?

Yes.

> So what is the moral of this story? To avoid repeating the story of
> -traditional, and instead make sure that users of -std=c89 always have a
 ^^
> flag they can use to indicate they are writing old c89 code?
>
> If so, then as far as I can tell, that was the original plan? The flag
> already exists, even. And the original proposal was to provide another
> flag that doesn't even restrict you to c89.

And what will guarantee this ``always'' always remains true?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Sam James  writes:

> And I would not want to see that happen either, nor do I think Florian
> would, or many of the other participants in this thread.
>
> Indeed, for some projects, where it's hopeless^Wlots of work,
> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>
> But most things are easy to fix.
>
> Our interest is purely in making the default stricter for better UX,
> reducing the net amount of these bugs in the wild, and avoiding
> regressions when we fix these problems. Trying to remove C89 entirely
> would, if nothing else, be needlessly antagonistic, but some of the
> replies seem to act as if we have.

But programs are not using c89 or gnu89, right? They are using gnu99 and
gnu11.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu  writes:

> Sam James  writes:
>
>> And I would not want to see that happen either, nor do I think Florian
>> would, or many of the other participants in this thread.
>>
>> Indeed, for some projects, where it's hopeless^Wlots of work,
>> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>>
>> But most things are easy to fix.
>>
>> Our interest is purely in making the default stricter for better UX,
>> reducing the net amount of these bugs in the wild, and avoiding
>> regressions when we fix these problems. Trying to remove C89 entirely
>> would, if nothing else, be needlessly antagonistic, but some of the
>> replies seem to act as if we have.
>
> But programs are not using c89 or gnu89, right? They are using gnu99 and
> gnu11.

They're using > c89/gnu89 often because defaults have changed (a point
others have raised, including Arsen and Eli Schwartz) even though they
weren't intended to be compiled with newer C.

A fair amount of other projects do explicitly ask for either c99/gnu99
or c11/gnu11 and if they're doing that, they shouldn't be getting
something which was removed from the C standard. But if they really want
it, they can either downgrade to C89 (rather drastic), or set the
proposed -fpermissive.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Jason Merrill via Gcc]

On Thu, May 11, 2023 at 10:39 PM Po Lu via Gcc  wrote:
>
> Eli Schwartz  writes:
>
> > This discussion thread is about having very good technical reasons -- as
> > explained multiple times, including instances where you agreed that the
> > technical reasons were good.
> >
> > Furthermore, even despite those technical reasons, GCC is *still*
> > committed to not breaking those old programs anyway. GCC merely wants to
> > make those old programs have to be compiled in an "old-programs" mode.
> >
> > Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4

You shouldn't have to change any of those, just configure with CC="gcc
-fwhatever".

Jason

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> Eli Schwartz  writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

I've seen 0 instances of this. All of the fixes we've made have been
proper and all the fixes I've seen when I report but don't fix an
issue have been proper.

We wouldn't have proposed this if that was the case. Maybe you should
take your case to the C committee that removed the feature in the first
place and tell them to reinstate it because of.. ^


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> Eli Schwartz  writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

In addition to Jason's point about just setting CC, I'd also expect
there to be a few centralised places where the flags are set in most
projects anyway.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 10:08 PM, Po Lu wrote:
>> I do not consider that you are being told what to do with your code.
>> Your code is not being broken. You may have to update your Makefile to
>  
> 
> My code is being broken.  There are thousands of Makefiles, Autoconf
> files containing configure tests, and so on.


There are ***not*** thousands of Makefiles that have this issue. But if
there were, then Makefiles are very easy to update, and only have to be
updated once per project, not thousands of times. So this is fine. You
may have to update your Makefile, but that is no big deal.

It's still no big deal, no matter how much you dramatize the intensity
of adding a flag to your Makefiles.


>> add a flag that turns off a changed default, but that does not
>> constitute being told what to do with your code, only being told what to
>> do with GCC.
> 
> That's GCC trying to tell me what to do with my own code.


So you concede that GCC is not telling you, only trying and failing to
tell you?

Great, so what's the problem? If GCC can't actually enforce it, and even
goes out of its way to offer you options to ignore what it's telling you
to do, then maybe...

... it's not telling you what to do with your code, only suggesting what
to do?

So ignore the suggestion.

I'm not sure what this semantics game here is trying to say. Is it
ethically and morally wrong for GCC to try to tell you what to do with
your code? Is it undignifying to have a mere machine go and lecture you,
a real human being with a consciousness and free will, what to do?

Because if that's what this is about then I think you are taking this
inanimate object way too personally.

If not, then I am simply entirely unsure what your objection is to being
"told".


>> Because that's exactly what is going on here. Features that were valid
>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>> ***not*** being valid GNU99 or GNU11 code.
> 
> How GCC currently behaves defines what is valid GNU C.


No. Absolutely positively 100% no under any circumstances whatsoever no.

This has been explained multiple times by the GCC developers. e.g.
search for references to accepts-invalid.

"""
They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
"""

You cannot, and are not permitted, to define "how GCC currently behaves"
as "defines what is valid GNU C". No one agrees with your analysis. Most
importantly, GCC does not agree with your analysis.

It's a wild, wild, wild claim to begin with. You are arguing that any
bug, ANY bug whatsoever, which qualifies for the title "how GCC
currently behaves" because if a bug is currently present, then GCC
currently behaves in a buggy manner...

... any such bug is, ***because*** GCC currently does it, now part of
the documentation on "GNU C", a language dialect with documentation.

Can you show me where on
https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
documentation states that "C Extensions include anything that GCC
currently does, no matter what, no matter how documented or undocumented"?


>> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
>> make it a GNU extension. It compiles with a warning in c11 mode too,
>> does that make it a c11 extension? No it does not.
> 
> Except it does?  Since the compiler is defining behavior that is
> otherwise undefined (i.e. the behavior of a program after a diagnostic
> is emitted after encountering an erroneous construct), it is defining
> an extension.


The concept of a language extension has bulletproof meaning. You cannot
get around it, redefine it, pretend that something is when it isn't, or
otherwise disagree with this bulletproof meaning.

The compiler defines an extension by writing about it in its
documentation on "GNU C extensions".

Anything else you have to say on the topic is automatically wrong.

Language has meaning. *Words* have meaning. The word "extension" has a
very specific meaning in the GCC documentation. You can read all about
it, here: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html


>> I am not dictating anything to you or anyone else in this paragraph,
>> though? All I said was that if one writes a c89 program and tells the
>> compiler that, then they will not even notice this entire discussion to
>> begin with.
>>
>> What, precisely, have I dictated?
> 
> That people who are writing GNU C code should be forced to rewrite their
> code in ANSI C, in order to make use of GNU C extensions to the 1999
> Standard.


I did not dictate that you have to rewrite your code. You are replying
to something that has no relationship whatsoever to any form of
instruction, telling, or even ***ad

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 10:39 PM, Po Lu wrote:
>> If so, then as far as I can tell, that was the original plan? The flag
>> already exists, even. And the original proposal was to provide another
>> flag that doesn't even restrict you to c89.
> 
> And what will guarantee this ``always'' always remains true?


Nothing. The future has not happened yet, so it cannot be guaranteed. As
I said in a previous reply, the earth may be struck by a meteor and
annihilate all life on earth. I cannot guarantee for you that such an
event will never happen.

All I can say is that I think it is pretty unlikely and not worth
worrying about.

And similarly, I can say about your concern, that I think it is pretty
unlikely.

If you will not be satisfied by anything less than a "guarantee" then I
don't know what to say. Maybe hire a lawyer and draw up a contract that
you convince the GCC developers to sign, saying that they are not
legally allowed to remove the flag? Would this make you happy?


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Sam James  writes:

> They're using > c89/gnu89 often because defaults have changed (a point
> others have raised, including Arsen and Eli Schwartz) even though they
> weren't intended to be compiled with newer C.
>
> A fair amount of other projects do explicitly ask for either c99/gnu99
> or c11/gnu11 and if they're doing that, they shouldn't be getting
> something which was removed from the C standard. But if they really want
> it, they can either downgrade to C89 (rather drastic), or set the
> proposed -fpermissive.

Too much trouble.

Let me tell you what will actually happen: people will never do what you
want them to.  Instead, they will simply write:

  extern int foo ();

above the new errors.  As a result, you will not have really
accomplished anything other than making a lot of users angry.  The
declarations will continue to be as correct as they have always been.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> There are ***not*** thousands of Makefiles that have this issue. But if
> there were, then Makefiles are very easy to update, and only have to be
> updated once per project, not thousands of times. So this is fine. You
> may have to update your Makefile, but that is no big deal.
>
> It's still no big deal, no matter how much you dramatize the intensity
> of adding a flag to your Makefiles.

It's extra work.  Why don't I just write:

  extern int foo ();

above each of the new errors?
That is just about what anyone will do when confronted by these new
errors.  As a result, you have not ensured that any declarations are
correct, but instead you have annoyed a lot of people and lulled
yourself into a false sense of safety.

> So you concede that GCC is not telling you, only trying and failing to
> tell you?

I concede that you're playing with words.

> Great, so what's the problem? If GCC can't actually enforce it, and even
> goes out of its way to offer you options to ignore what it's telling you
> to do, then maybe...
>
> ... it's not telling you what to do with your code, only suggesting what
> to do?
>
> So ignore the suggestion.

Which is made annoying, especially when there is absolutely NO guarantee
being made that the new option will stay.

> I'm not sure what this semantics game here is trying to say. Is it
> ethically and morally wrong for GCC to try to tell you what to do with
> your code? Is it undignifying to have a mere machine go and lecture you,
> a real human being with a consciousness and free will, what to do?
>
> Because if that's what this is about then I think you are taking this
> inanimate object way too personally.
>
> If not, then I am simply entirely unsure what your objection is to being
> "told".
>
>
>>> Because that's exactly what is going on here. Features that were valid
>>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>>> ***not*** being valid GNU99 or GNU11 code.
>> 
>> How GCC currently behaves defines what is valid GNU C.
>
>
> No. Absolutely positively 100% no under any circumstances whatsoever no.
>
> This has been explained multiple times by the GCC developers. e.g.
> search for references to accepts-invalid.
>
> """
> They are bugs where compiler accepts something that isn't valid in
> the selected language nor considered valid extension.
> So, after the fix we reject something that has been accepted before.
>
> In the last few years (checked what was fixed in 10/11/12/13 releases so
> far), we've fixed 12 such bugs explicitly marked that way:
> """

The Standard states that each conforming implementation must be
accompanied by a document which documents each and every extension.

This document is the GCC manual, which makes reference (not too clearly,
however, which should be fixed) to both implicit int and implicit
function declarations, which are allowed in C99 and later dialects of C.

These constructs are not bugs.  These constructs explicitly defined by
GNU C; since a diagnostic is issued, GNU C's implementation also
conforms to the Standard.

> You cannot, and are not permitted, to define "how GCC currently behaves"
> as "defines what is valid GNU C". No one agrees with your analysis. Most
^^

I'm not a person?

> importantly, GCC does not agree with your analysis.

For some definition of GCC, which is apparently you.

> It's a wild, wild, wild claim to begin with. You are arguing that any
> bug, ANY bug whatsoever, which qualifies for the title "how GCC
> currently behaves" because if a bug is currently present, then GCC
> currently behaves in a buggy manner...
>
> ... any such bug is, ***because*** GCC currently does it, now part of
> the documentation on "GNU C", a language dialect with documentation.
>
> Can you show me where on
> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
> documentation states that "C Extensions include anything that GCC
> currently does, no matter what, no matter how documented or undocumented"?

I see:

`-Wno-implicit-int (C and Objective-C only)'
 This option controls warnings when a declaration does not specify a
 type.  This warning is enabled by default in C99 and later dialects
 of C, and also by `-Wall'.

`-Wno-implicit-function-declaration (C and Objective-C only)'
 This option controls warnings when a function is used before being
 declared.  This warning is enabled by default in C99 and later
 dialects of C, and also by `-Wall'.  The warning is made into an
 error by `-pedantic-errors'.

> The concept of a language extension has bulletproof meaning. You cannot
> get around it, redefine it, pretend that something is when it isn't, or
> otherwise disagree with this bulletproof meaning.

The concept of a ``language extension'' is not defined anywhere.
Instead, there are three kinds of behavior not precisely specified by
the Standard:

  - undefined behavior, the behavior upon use of an erroneous const

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jason Merrill  writes:

> You shouldn't have to change any of those, just configure with CC="gcc
> -fwhatever".

If it were so simple...

Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
`cc', to build programs which are run on the build machine.

These programs are intended to be as portable as possible (naturally,
since Autoconf does not configure for the build machine).  As a result,
they are typically written in the subset of ANSI C that will compile
with almost any C compiler, which is exactly what will cause problems
with GCC's proposed new defaults.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Thu, 11 May 2023 18:30:20 -0400
> Cc: luang...@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz 
> 
> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
> > 
> > He is telling you that removing support for these old features, you
> > draw users away from GCC and towards proprietary compilers.
> > 
> > One of the arguments in this thread _for_ dropping that support was
> > that by not rejecting those old programs, GCC draws some users away
> > from GCC.  He is telling you that this change will, perhaps, draw some
> > people to GCC, but will draw others away from GCC.  The difference is
> > that the former group will start using Clang, which is still free
> > software (at least some of its versions), whereas the latter group has
> > nowhere to go but to proprietary compilers.  So the FOSS community
> > will have suffered a net loss.  Something to consider, I think.
> 
> But I do not understand the comparison to -traditional. Which was
> already removed, and already resulted in, apparently, at least one group
> being so adamant on not-C that it switched to a proprietary compiler.
> Okay, understood. But at this point that group is no longer users of
> GCC... right?
> 
> So what is the moral of this story?

See above: that repeating the story of -traditional could result in
net loss for the FOSS movement.

> To avoid repeating the story of -traditional, and instead make sure
> that users of -std=c89 always have a flag they can use to indicate
> they are writing old c89 code?

No, the moral is not to introduce breaking behavior without very good
technical reasons.

Re: [wish] Flexible array members in unions

[Richard Biener via Gcc]

On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc  wrote:
>
> On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> > On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> >
> > > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > > On 5/11/23 18:07, Alejandro Colomar wrote:
> > > > [...]
> > > > > Would you allow flexible array members in unions?  Is there any
> > > > > strong reason to disallow them?
> > >
> > > Yes please!! And alone in a struct, too.
> > >
> > > AFAICT, there is no mechanical/architectural reason to disallow them
> > > (especially since they _can_ be constructed with some fancy tricks,
> > > and they behave as expected.) My understanding is that it's disallowed
> > > due to an overly strict reading of the very terse language that created
> > > flexible arrays in C99.
> >
> > Standard C has no such thing as a zero-size object or type, which would
> > lead to problems with a struct or union that only contains a flexible
> > array member there.
>
> Ah-ha, okay. That root cause makes sense now.

Hmm. but then the workaround

struct X {
  int n;
  union u {
  char at_least_size_one;
  int iarr[];
  short sarr[];
  };
};

doesn't work either.  We could make that a GNU extension without
adverse effects?

Richard.

> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> question is: what's needed to support the idea of a zero-sized object?
>
> --
> Kees Cook

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Thu, 11 May 2023 18:43:32 -0400
> Cc: luang...@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz 
> 
> On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> 
> > Back to the subject: the guarantees I would personally like to have is
> > that the current GCC development team sees backward compatibility as
> > an important goal, and will try not to break old programs without very
> > good technical reasons.  At least in Emacs development, that is the
> > consideration that is very high on our priority list when making
> > development decisions.  It would be nice if GCC (and any other GNU
> > project, for that matter) would do the same, because being able to
> > upgrade important tools and packages without fear is something users
> > value very much.  Take it from someone who uses GCC on various
> > platforms since version 1.40.
> 
> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.

They are not technical, no.  Leaving the current behavior does not
technically hamper GCC and its users in any way -- GCC can still
compile the same programs, including those with modern std= values, as
it did before, and no false warnings or errors are caused when
compiling programs written in valid standard C.

The reasons are basically PR: better reputation for GCC etc.  Maybe
even fashion: Clang does that, so how come we don't?

> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not breaking those old programs anyway. GCC merely wants to
> make those old programs have to be compiled in an "old-programs" mode.
> 
> Can you explain to me how you think this goal conflicts with your goal?

I already did, in previous messages, where I described what we all are
familiar with: the plight of a maintainer of a large software system
whose build suddenly breaks, and the difficulty in understanding which
part of the system's upgrade caused that.  I'd rather not repeat that:
there are already too many repetitions here that make the discussion
harder to follow.

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Fri, 12 May 2023, 07:02 Po Lu via Gcc,  wrote:

> Jason Merrill  writes:
>
> > You shouldn't have to change any of those, just configure with CC="gcc
> > -fwhatever".
>
> If it were so simple...
>
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on the build machine.
>
> These programs are intended to be as portable as possible (naturally,
> since Autoconf does not configure for the build machine).  As a result,
> they are typically written in the subset of ANSI C that will compile
> with almost any C compiler, which is exactly what will cause problems
> with GCC's proposed new defaults.
>

Then they should not use implicit int and implicit function declarations.

You've made your opinion clear. It has been noted.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Jason Merrill 
> Date: Thu, 11 May 2023 22:55:07 -0400
> Cc: Eli Schwartz , Eli Zaretskii , 
> gcc@gcc.gnu.org
> 
> > Because now people will have to go through dozens and dozens of
> > Makefiles, configure.in, *.m4
> 
> You shouldn't have to change any of those, just configure with CC="gcc
> -fwhatever".

That doesn't always work.  Whether it works or not depends on how the
Makefile's are written, whether libtool is or isn't being used, etc.

So yes, it will work in some, perhaps many, cases, but not in all of
them.

Moreover, the main problem with such a change is discovering that the
build broke because of different GCC defaults, and that adding
"-fpermissive" is all that's needed to pacify GCC.  I already tried to
explain why this is nowhere as simple in real life as some people here
seem to assume.  The aggravation and frustration caused by that
process of discovery is the main downside of this proposal, and I hope
it will be considered very seriously when making the decision.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Thu, 11 May 2023 23:07:55 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc 
> 
> > Being sceptical about the future is perfectly reasonable.
> 
> My opinion on this is (still) that if your argument is that you don't
> want -fpermissive or -std=c89 to be removed, you are more than welcome
> to be skeptical about that (either one or both), but I don't see why
> that is on topic for the question of whether things should be moved to
> flags such as those while they do exist.

It is on topic because there doesn't seem to be anything in the
arguments brought up for this current proposal that couldn't be
brought up in favor of removing -fpermissive.  There are no guiding
principles being uttered which allow the current proposal, but will
disallow the removal of -fpermissive.  The same "let's be more popular
and forthcoming to newbies, and more like Clang" PR-style stuff can
justify both.

> We might as well assume that the GCC developers are honest and truthful
> people, otherwise it is *definitely* a waste of time asking them about
> this change in the first place.

This is not about honesty.  No one is questioning the honesty of GCC
developers.  What is being questioned are the overriding principles
that should be applied when backward-incompatible changes are
proposed.  Are there such principles in GCC development, and if there
are, where are they documented?  Or are such discussions just some
ad-hoc disputes, and the results are determined by which party is at
that time more vocal?