Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, 07:56 Eli Zaretskii via Gcc, wrote: > > 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 do

Re: [wish] Flexible array members in unions

On Thu, 11 May 2023, 23:17 Kees Cook via Gcc, wrote: > 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

Re: More C type errors by default for GCC 14

> From: Arsen Arsenović > Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org > Date: Thu, 11 May 2023 21:25:53 +0200 > > >> 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 beginn

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote: > > From: Arsen Arsenović > > Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org > > Date: Thu, 11 May 2023 21:25:53 +0200 > > > > >> This seems like a good route to me - it facilitates both veterans > > >> maintai

Re: More C type errors by default for GCC 14

On 5/12/23 09:53, Eli Zaretskii via Gcc wrote: With all that to consider, is it *really* a significant cost to add -fpermissive? See above (and my earlier message): the significant cost is to discover the root cause of the problem, and that -fpermissive is the solution. The rest might be rel

Re: More C type errors by default for GCC 14

On 12.05.23 09:53, Eli Zaretskii via Gcc wrote: I described in an earlier message how this breakage looks in real life, and why it causes a lot of frustration. The main problem is discovering that things broke because GCC defaults, and then discovering how to pacify GCC with the least effort.

Re: More C type errors by default for GCC 14

Hi, On Tue, May 09 2023, Florian Weimer via Gcc wrote: > TL;DR: This message is about turning implicit-int, > implicit-function-declaration, and possibly int-conversion into errors > for GCC 14. > FWIW, I personally support the proposal. Regarding the huge discussion that ensued, I would just li

Re: Wish: scoped enum

Arsen, Gabriel, Thanks for your feedback. I read through the n2347 article, and I believe that your feedback is to leverage the C++ 'enum struct' grammer. As you can tell, I'm not a C++, and and I did not know that the 'SCOPED enum' is already available for using 'enum class' or 'enum struct'. Lev

Re: Wish: scoped enum

rsen, Gabriel, Thanks for your feedback. I read through the n2347 article, and I believe that your feedback is to leverage the C++ 'enum struct' grammer. As you can tell, I'm not a C++, and and I did not know that the 'SCOPED enum' is already available for using 'enum class' or 'enum struct'. Leve

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023 at 09:46, Christian Groessler wrote: > > On 5/12/23 09:53, Eli Zaretskii via Gcc wrote: > > > >> With all that to consider, is it *really* a significant cost to add > >> -fpermissive? > > > > See above (and my earlier message): the significant cost is to > > discover the root c

Re: More C type errors by default for GCC 14

> From: Jonathan Wakely > Date: Fri, 12 May 2023 08:28:00 +0100 > Cc: Eli Schwartz , Po Lu , > "gcc@gcc.gnu.org" > > 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 -fper

Re: More C type errors by default for GCC 14

> Date: Fri, 12 May 2023 10:15:45 +0200 > From: Jakub Jelinek > Cc: Arsen Arsenović , luang...@yahoo.com, > jwakely@gmail.com, gcc@gcc.gnu.org > > On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote: > > > > Let's keep in mind that veterans are much more likely to h

Re: More C type errors by default for GCC 14

On 2023-05-12 7:01 a.m., 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

Re: More C type errors by default for GCC 14

On 5/12/23 07:57, Po Lu via Gcc wrote: 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

Re: More C type errors by default for GCC 14

On 5/12/23 08:25, Eli Zaretskii via Gcc wrote: 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

Re: More C type errors by default for GCC 14

On 12/05/2023 04:08, Po Lu via Gcc wrote: Eli Schwartz writes: 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 va

Is the GNUC dialect anything that GCC does when given source code containing UB? (Was: More C type errors by default for GCC 14)

On 5/12/23 1:57 AM, Po Lu wrote: > Eli Schwartz writes: >> 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

Re: More C type errors by default for GCC 14

On 5/12/23 2:01 AM, Po Lu 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 th

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote: > > One fairly big GCC-internal task is to clear up the C test suite so that > > it passes with the new compiler defaults. I already have an offer of > > help for that, so I think we can complete this work in a reasonable time > > fram

Re: More C type errors by default for GCC 14

On 5/12/23 04:36, Po Lu via Gcc wrote: 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 t

Re: [wish] Flexible array members in unions

On 12/05/2023 08:16, Richard Biener via Gcc wrote: 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/1

Re: Is the GNUC dialect anything that GCC does when given source code containing UB?

Eli Schwartz writes: > Instead of adding one flag to their Makefile, which is too much work, Once again, you're making the silly assumption that adding `-fpermissive' to many different Makefiles is easy. Especially when the Makefiles also have to be used with compilers which do not understand s

Re: More C type errors by default for GCC 14

Jonathan Wakely writes: > It's not about popularity. If that's your takeaway then you're not > paying attention, whatever you claim about reading everything in the > thread. It's about helping people write correct code, first time, > without some of the avoidable traps that C presents. > > The C

Re: More C type errors by default for GCC 14

Jonathan Wakely writes: > Then they should not use implicit int and implicit function > declarations. And why is that? Is GCC really arrogant enough to think that it is the only C translator in the world? BTW, standards.info used to say something along the lines of: Do not declare functions

Re: More C type errors by default for GCC 14

On 5/12/23 15:19, Po Lu via Gcc wrote: Jonathan Wakely writes: It's not about popularity. If that's your takeaway then you're not paying attention, whatever you claim about reading everything in the thread. It's about helping people write correct code, first time, without some of the avoidabl

Re: More C type errors by default for GCC 14

Pedro Alves writes: > Then write a wrapper script named "cc", and put that in the PATH: > > $ cat cc > #!/bin/sh > > exec /my/real/gcc -fwhatever "$@" > > Done. And how many people are going to be forced to do this? Though this is a good point: I suspect if such an option were actually added

Re: More C type errors by default for GCC 14

Gabriel Ravier writes: > It's "extra work" to add 10 characters to a Makefile, but normal to > add random faulty declarations everywhere ? You're assuming that people are willing to edit Makefiles, which is all kinds of pain, and then put up with a complete recompile of whatever software is bei

Re: More C type errors by default for GCC 14

Eli Schwartz writes: > This sounds like a "you" problem. I don't write these Makefiles. Others do. It wasn't the problem of their authors before, so why should it be now?

Re: More C type errors by default for GCC 14

Gabriel Ravier writes: > As somebody that spends a lot of time helping beginners, yes, > constantly. I'd go as far as to say it's an error that seemingly > everyone has made at least once. Really? And after making this mistake (and learning its solution), did they continue to make the same mist

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023 at 14:54, Po Lu via Gcc wrote: > From my perspective, I also see only a few extremely loud people > repeating the same arguments over and over. Maybe stop then? > But how many times have I > mentioned that? The number of people in this thread is too small to > conclude anyth

Re: [PATCH v5 3/5] p1689r5: initial support

On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote: > I notice that the actual flags are all -fdep-*, though some of them are > -fdeps-* here, and the internal variables all seem to be fdeps_*. I > lean toward harmonizing on "deps", I think. Done. > I don't love the three separate opt

Re: [PATCH v5 1/5] libcpp: reject codepoints above 0x10FFFF

On Mon, Feb 13, 2023 at 10:53:17 -0500, Jason Merrill wrote: > On 1/25/23 13:06, Ben Boeckel wrote: > > Unicode does not support such values because they are unrepresentable in > > UTF-16. > > > > libcpp/ > > > > * charset.cc: Reject encodings of codepoints above 0x10. > > UTF-16 does

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On Mon, Feb 13, 2023 at 13:33:50 -0500, Jason Merrill wrote: > Both this and the mapper dependency patch seem to cause most of the > modules testcases to crash; please remember to run the regression tests > (https://gcc.gnu.org/contribute.html#testing) Fixed for v6. `cpp_get_deps` can return `NU

Re: More C type errors by default for GCC 14

* Joseph Myers: > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: > >> That is not the case we are discussing, AFAIU. Or at least no one has >> yet explained why accepting those old K&R programs will adversely >> affect the ability of GCC to compile C2x programs. > > At block scope, > > auto

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 9:20 AM Po Lu via Gcc wrote: > Yes, just these quotes from a former GCC maintainer: > > In C, we cannot divide all user code into "right" and "wrong" in this > kind of simple way, and certainly not based on the ISO standard. That > standard is just the decisions of a

Re: More C type errors by default for GCC 14

* Florian Weimer: > In summary, all these seems to be good candidates for errors by default: > > * int-conversion as errors (already raised separately > * -Wint-conversion for ?: > * parameter names in non-prototype function declarations > * the union wait function pointer compatibility kludge > *

Re: More C type errors by default for GCC 14

On 5/12/23 19:52, Florian Weimer wrote: * Florian Weimer: In summary, all these seems to be good candidates for errors by default: * int-conversion as errors (already raised separately * -Wint-conversion for ?: * parameter names in non-prototype function declarations * the union wait function

Re: More C type errors by default for GCC 14

* Gabriel Ravier: > On 5/12/23 19:52, Florian Weimer wrote: >> * Florian Weimer: >> >>> In summary, all these seems to be good candidates for errors by default: >>> >>> * int-conversion as errors (already raised separately >>> * -Wint-conversion for ?: >>> * parameter names in non-prototype functi

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, Gabriel Ravier via Gcc wrote: > On 5/12/23 19:52, Florian Weimer wrote: > > I think we have another problem. > > > > We do not warn by default for: > > > >int x; > >unsigned *p; > > > >p = &x; > > > > Isn't that a conformance issue because the pointers are incomp

Re: More C type errors by default for GCC 14

* Alexander Monakov: > This is not valid (constraint violation): > > unsigned x; > > int *p = &x; > > In GCC this is diagnosed under -Wpointer-sign: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892 Thanks for the reference. I filed: -Wpointer-sign must be enabled by default

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, Florian Weimer wrote: > This sone seems to be a good candidate for additional errors, though: > > warned_here = pedwarn > (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0, > "% with no value, in function returning non-void"); > > It's a clear type volation that

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: > > * Joseph Myers: > > > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: > > > >> That is not the case we are discussing, AFAIU. Or at least no one has > >> yet explained why accepting those old K&R programs will adversely > >> affect the

Re: More C type errors by default for GCC 14

* Joseph Myers: > On Fri, 12 May 2023, Florian Weimer wrote: > >> This sone seems to be a good candidate for additional errors, though: >> >> warned_here = pedwarn >> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0, >> "% with no value, in function returning non-void"); >> >> It's

Re: More C type errors by default for GCC 14

* Jason Merrill: > On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: >> >> * Joseph Myers: >> >> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: >> > >> >> That is not the case we are discussing, AFAIU. Or at least no one has >> >> yet explained why accepting those old K&R programs will

Re: More C type errors by default for GCC 14

Florian Weimer writes: > * Jason Merrill: > >> On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: >>> >>> * Joseph Myers: >>> >>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: >>> > >>> >> That is not the case we are discussing, AFAIU. Or at least no one has >>> >> yet explained why

Re: More C type errors by default for GCC 14

Florian Weimer writes: > [...] > In summary, all these seems to be good candidates for errors by default: > > * int-conversion as errors (already raised separately > * -Wint-conversion for ?: > * parameter names in non-prototype function declarations > * the union wait function pointer compatibi

Re: More C type errors by default for GCC 14

* Sam James: > Florian Weimer writes: > >> [...] >> In summary, all these seems to be good candidates for errors by default: >> >> * int-conversion as errors (already raised separately >> * -Wint-conversion for ?: >> * parameter names in non-prototype function declarations >> * the union wait fun

Re: More C type errors by default for GCC 14

Florian Weimer writes: > * Sam James: > >> Florian Weimer writes: >> >>> [...] >>> In summary, all these seems to be good candidates for errors by default: >>> >>> * int-conversion as errors (already raised separately >>> * -Wint-conversion for ?: >>> * parameter names in non-prototype functio

Re: More C type errors by default for GCC 14

* Sam James: > Florian Weimer writes: > >> * Sam James: >> >>> Florian Weimer writes: >>> [...] In summary, all these seems to be good candidates for errors by default: * int-conversion as errors (already raised separately * -Wint-conversion for ?: * parameter names

gcc-12-20230512 is now available

Snapshot gcc-12-20230512 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20230512/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: More C type errors by default for GCC 14

Gabriel Ravier writes: > ...You're joking, right ? You can't possibly be seriously arguing > this, you have to be kidding... right ? No, I'm not. The meaning of a variable declaration with only a storage class specifier is extremely clear: the type of the variable is `int'. There's absolutely n

Re: More C type errors by default for GCC 14

On 13.05.23 02:45, Po Lu via Gcc wrote: Gabriel Ravier writes: ...You're joking, right ? You can't possibly be seriously arguing this, you have to be kidding... right ? No, I'm not. The meaning of a variable declaration with only a storage class specifier is extremely clear: the type of the

Re: More C type errors by default for GCC 14

Thomas Koenig writes: > C99, 6.7.2, "Type specifiers" > > # Constraints > > # At least one type specifier shall be given in the declaration > # specifiers in each declaration, and in the specifier-qualifier > # list in each struct declaration and type name. And? > In C99 and onwards, this is an