* Jason Merrill:
> As a compromise, it should be possible to error by default only in
> cases where the implicit int (including as a return value) is either
> the source or target of a non-value-preserving conversion, as those
> are very likely to be bugs. That seems desirable for both camps.
On Tue, May 16, 2023 at 3:06 AM Florian Weimer via Gcc
wrote:
> * Eric Gallager via Gcc:
>
> > I support this plan for using -Werror= and having it be split based on
> > whether -std= is set to a strict ANSI option or a GNU option; is there
> > a way to do that in the optfiles, or would it have
* Jakub Jelinek:
> On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
>>
>> On Tue, 16 May 2023, Florian Weimer wrote:
>>
>> > > (FWIW: no, this should not be an error, a warning is fine, and I
>> > > actually
>> > > think the current state of it not being in Wall is the right
On Tue, 16 May 2023 at 12:01, Jakub Jelinek wrote:
>
> On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
> >
> > On Tue, 16 May 2023, Florian Weimer wrote:
> >
> > > > (FWIW: no, this should not be an error, a warning is fine, and I
> > > > actually
> > > > think the current
On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
>
> On Tue, 16 May 2023, Florian Weimer wrote:
>
> > > (FWIW: no, this should not be an error, a warning is fine, and I actually
> > > think the current state of it not being in Wall is the right thing as
> > > well)
>
> (this
On Tue, 16 May 2023, Florian Weimer wrote:
> > (FWIW: no, this should not be an error, a warning is fine, and I actually
> > think the current state of it not being in Wall is the right thing as
> > well)
(this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
> I don't understand
* Michael Matz:
> Hello,
>
> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> * Alexander Monakov:
>>
>> > This is not valid (constraint violation):
>> >
>> > unsigned x;
>> >
>> > int *p =
>> >
>> > In GCC this is diagnosed under -Wpointer-sign:
>> >
>> >
* Eric Gallager via Gcc:
> I support this plan for using -Werror= and having it be split based on
> whether -std= is set to a strict ANSI option or a GNU option; is there
> a way to do that in the optfiles, or would it have to be handled at
> the specs level instead?
This isn't going to work
On 5/15/23, Richard Earnshaw (lists) via Gcc wrote:
> On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
>>> From: Arsen Arsenović
>>> Cc: Eli Zaretskii , Jakub Jelinek ,
>>> jwakely@gmail.com, gcc@gcc.gnu.org
>>> Date: Tue, 09 May 2023 22:21:03 +0200
>>>
The concern is using the good
On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote:
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
Hello,
On Fri, 12 May 2023, Florian Weimer wrote:
> * Alexander Monakov:
>
> > This is not valid (constraint violation):
> >
> > unsigned x;
> >
> > int *p =
> >
> > In GCC this is diagnosed under -Wpointer-sign:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
>
> Thanks for
Hello,
On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote:
> 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
On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
From: Arsen Arsenović
Cc: Eli Zaretskii , Jakub Jelinek ,
jwakely@gmail.com, gcc@gcc.gnu.org
Date: Tue, 09 May 2023 22:21:03 +0200
The concern is using the good will of the GNU Toolchain brand as the tip of
the spear or battering ram to
Arsen Arsenović writes:
> Any development style making documentation a source of truth matches
> this principle. This does not refer to ISO specifications specifically,
> though, normally, unless the standard disagrees with reality, as
> implicit-... did many years ago, ISO decisions are taken
Jonathan Wakely writes:
Wrong. I wouldn't bother replying to you again in this thread, but I
feel that as a gcc maintainer I should confirm that Eli S. is right
here; and nobody else I know agrees with your definition of extension
as "every non-standard aspect of the compiler's behaviour,
Po Lu via Gcc writes:
...
> Where is it written that GNU CC follows your so-called
> ``specification-driven development''?
Any development style making documentation a source of truth matches
this principle. This does not refer to ISO specifications specifically,
though, normally, unless the
Hi Po,
On Fri, May 12, 2023 at 09:53:30PM +0800, Po Lu via Gcc wrote:
> I don't want anything, seeing as I've been using GCC less and less over
> the years (for this and other reasons.) I'm just throwing in my two or
> so cents.
I think you have contributed more than two cents and it time to
Jonathan Wakely writes:
> Wrong. I wouldn't bother replying to you again in this thread, but I
> feel that as a gcc maintainer I should confirm that Eli S. is right
> here; and nobody else I know agrees with your definition of extension
> as "every non-standard aspect of the compiler's
Eli Schwartz writes:
> Does this mean you've conceded the point, and no longer think it is
> written in C++?
No.
> You are correct in reading my sentence, that is indeed what I said.
>
> Aside: you have reiterated "the behavior of the translator itself" over
> and over again, but it hasn't
On 14/05/2023 07:28, Po Lu via Gcc wrote:
Eli Schwartz writes:
Quoting my previous reply on the topic.
Until everyone is on the same page as you about whether these are GNUC
extensions, this conversation will go nowhere.
You are of the opinion that "GCC currently behaves a certain way when
On Sun, 14 May 2023, 11:21 Jonathan Wakely, wrote:
>
>
> On Sun, 14 May 2023, 10:47 David Brown, wrote:
>
>> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>>
>> > No, all you have to do is to tell GNU CC to compile Standard C. But
>> > what's being debated here is the behavior of GNU CC when
On Sun, 14 May 2023, 10:47 David Brown, wrote:
> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>
> > No, all you have to do is to tell GNU CC to compile Standard C. But
> > what's being debated here is the behavior of GNU CC when translating
> > both Standard C and GNU C, so your demonstration is
On 14/05/2023 07:38, Po Lu via Gcc wrote:
No, all you have to do is to tell GNU CC to compile Standard C. But
what's being debated here is the behavior of GNU CC when translating
both Standard C and GNU C, so your demonstration is almost completely
pointless.
You keep using the term
On Sun, 14 May 2023, 06:28 Po Lu, wrote:
> Eli Schwartz writes:
>
> > Quoting my previous reply on the topic.
> >
> > Until everyone is on the same page as you about whether these are GNUC
> > extensions, this conversation will go nowhere.
> >
> > You are of the opinion that "GCC currently
On 5/14/23 1:28 AM, Po Lu wrote:
>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't
On 5/14/23 1:28 AM, Po Lu wrote:
>> GCC has formal documentation. It is written in HTML. If it is lacking,
>> then the only valid move is to improve the HTML documentation and then
>> abide by it. In the absence of documentation, all behavior is, well,
>> "undocumented", which ***definitely***
Eli Schwartz writes:
> GNU C does not define any such thing. It may happen to turn out that
> way, but that is not the same as defining its behavior.
It is.
>> Nor does GCC conform to the Standard by default: while it is okay for a
>> conforming implementation to translate programs relying on
Eli Schwartz writes:
> Quoting my previous reply on the topic.
>
> Until everyone is on the same page as you about whether these are GNUC
> extensions, this conversation will go nowhere.
>
> You are of the opinion that "GCC currently behaves a certain way when
> compiling the code" means that
On 5/13/23 1:53 AM, Po Lu wrote:
> There are no ``errors'' in Standard C (with the possible exception of
> the #error preprocessing directive), only constraint and syntax rule
> violations. Such violations are required to generate diagnostic
> messages, after which the behavior of the translator
On 5/12/23 8:45 PM, Po Lu 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
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
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
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
* 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
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
* 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
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
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
* 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 programs will
* 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
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 programs will adversely
> >> affect the
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
* Alexander Monakov:
> This is not valid (constraint violation):
>
> unsigned x;
>
> int *p =
>
> 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
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 =
> >
> > Isn't that a conformance issue because the pointers are
* 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
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
* 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
>
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
* 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 programs will adversely
>> affect the ability of GCC to compile C2x programs.
>
> At block scope,
>
> auto x
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
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
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?
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
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
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
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
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
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
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
> >
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
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
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
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
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
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
> 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
> 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
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
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
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.
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
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
> > >>
> 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
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
> 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
> 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
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
> 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
> 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.
> >
>
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
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
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
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?
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
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
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
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
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 -
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
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
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
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
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
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
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
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.
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
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
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
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
1 - 100 of 243 matches
Mail list logo
