Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

> 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

Re: More C type errors by default for GCC 14

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 wh

Re: More C type errors by default for GCC 14

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

Re: [wish] Flexible array members in unions

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 wro

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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/g

Re: More C type errors by default for GCC 14

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? No

Re: More C type errors by default for GCC 14

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 thousa

Re: More C type errors by default for GCC 14

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 *

Re: More C type errors by default for GCC 14

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 *

Re: More C type errors by default for GCC 14

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 desp

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 n

Re: More C type errors by default for GCC 14

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 breakin

Re: More C type errors by default for GCC 14

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 suff

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 gen

Re: [wish] Flexible array members in unions

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 appro

Re: Wish: scoped enum

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

Re: Wish: scoped enum

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 {

Wish: scoped enum

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

Re: [wish] Flexible array members in unions

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

Re: More C type errors by default for GCC 14

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 state

Re: More C type errors by default for GCC 14

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

gcc-11-20230511 is now available

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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

Re: [wish] Flexible array members in unions

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

Re: [wish] Flexible array members in unions

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 princ

Re: More C type errors by default for GCC 14

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

Re: [wish] Flexible array members in unions

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 unio

Re: More C type errors by default for GCC 14

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 ad

Re: [wish] Flexible array members in unions

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

Re: [wish] Flexible array members in unions

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/a

Re: More C type errors by default for GCC 14

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 stric

Re: [wish] Flexible array members in unions

[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 [] syn

[wish] Flexible array members in unions

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.

Re: More C type errors by default for GCC 14

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

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

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 b

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 whe

Re: More C type errors by default for GCC 14

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, implic

Re: More C type errors by default for GCC 14

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 refer

Re: More C type errors by default for GCC 14

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

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

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 const

Re: More C type errors by default for GCC 14

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.

Re: More C type errors by default for GCC 14

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 whi

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 >