Re: More C type errors by default for GCC 14
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 cause it to be >> defined and documented, and your trust will, if you are wise, depend >> on you pinning an exact source code commit of the compiler. Do not >> depend on bugfix releases of GCC to preserve your undocumented >> semantics. They may or they may not, but if they don't, it's not a GCC >> bug, because it is ***undocumented***. > > GCC does not implement its documentation. The documentation is supposed > to describe (_not_ specify) how GCC behaves, and when the documentation > is wrong or contains omissions, the documentation will have to be fixed. > Not the compiler itself. > > And it's not just GCC. Almost all programs work this way. But perhaps we can solve this argument. Please submit a bug report at https://gcc.gnu.org/bugzilla/ to report that the documentation is wrong or contains omissions, and has to be fixed. Point out that the C Extensions page omits the documentation on implicit function declarations and implicit ints. Consider including a patch that updates https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html to mention them as well. If and when this page is updated to document that the compiler's behavior with these features constitutes a C Extension, then I will withdraw every comment I have made in this thread. -- Eli Schwartz
Re: More C type errors by default for GCC 14
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*** means it isn't a formal GNUC >> language dialect extension. > > GCC documentation is written in HTML? That's news to me. I always > thought it was written in Texinfo. Does this mean you've conceded the point, and no longer think it is written in C++? :) >> You can stop arguing your opinions based on what running gcc or g++ >> produces in the form of machine code. What gcc or g++ produces in the >> form of machine code is not guaranteed even across bugfix releases -- >> your only guarantee is that if it is documented in the ISO standards >> documents or in the GCC html manual, the produced machine code shall be >> in accordance with what the documentation says it shall do. > > Generated machine code, really? Not long-standing and observable > behavior of the translator itself, as has been re-iterated over and over > again? 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 been generally reiterated, or even iterated. >> Undefined and undocumented behavior is not a language extension. It is >> undefined and undocumented behavior. > > But when it becomes defined by the translator, in a precise way, it > becomes an extension to the Standard. Repeating this statement won't make it true. >> 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 cause it to be >> defined and documented, and your trust will, if you are wise, depend >> on you pinning an exact source code commit of the compiler. Do not >> depend on bugfix releases of GCC to preserve your undocumented >> semantics. They may or they may not, but if they don't, it's not a GCC >> bug, because it is ***undocumented***. > > GCC does not implement its documentation. The documentation is supposed > to describe (_not_ specify) how GCC behaves, and when the documentation > is wrong or contains omissions, the documentation will have to be fixed. > Not the compiler itself. > > And it's not just GCC. Almost all programs work this way. In fact, lots and lots and lots of programs do indeed operate such that the documentation specifies how the program shall behave, and when the program fails to behave in the manner in which it is documented to behave, the program shall be fixed. We call these failures to behave according to the documentation, Bugs. Occasionally it is also called specification-driven development. ... In cases where the documentation says nothing at all, for good or ill, the behavior of the program is undefined -- users cannot rely on it, for they cannot know what is intended and what is not intended -- in this case, the intended behavior must be defined, documented, and implemented, and "the program currently does X" gets one vote out of many and is not guaranteed to get its way. Very often in such cases the best user-serving thing to do is to define the behavior as "shall not be used, and for legacy reasons if you use it it will continue to do X but raise a warning telling you that you are required to stop depending on it" and possibly even "it may disappear in semver version YYY". Sound familiar? A bit like GCC triggering a warning, telling you that what you're doing is bad and should not be relied on? But GCC isn't dropping support for it in semver version anything, just guarding its use behind an opt-in flag. -- Eli Schwartz
Re: More C type errors by default for GCC 14
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 ceases to be
> defined by the Standard, but GNU C defines it to mean that the type is
> int.
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.
> Nor does GCC conform to the Standard by default: while it is okay for a
> conforming implementation to translate programs relying on implicit int,
> as there is no way doing so will alter the behavior of any strictly
> conforming program, it is not okay to reserve keywords such as `asm'.
>
> The following strictly conforming program is thus not acceptable to GCC,
> unless GCC is operating in standards-conformance mode:
>
> int
> main (argc, argv)
> int argc;
> char **argv;
> {
> int asm;
> return asm = 0;
> }
>
> which shows that debating features based on the Standard is entirely
> pointless, as the Standard allows implementations to provide almost
> anything it prohibits.
Sure, all I have to do is tell GCC to act like a C compiler.
$ gcc -std=c2x /tmp/po.c -o /tmp/po; /tmp/po; echo $?
/tmp/po.c: In function ‘main’:
/tmp/po.c:2:3: warning: old-style function definition
[-Wold-style-definition]
2 | main (argc, argv)
| ^~~~
0
But I don't understand what point you are trying to make, anyway. The
Standard allows, but does not require, implementations to do many things
if it so chooses. GNUC takes advantage of this when operating in GNUC
mode, when also documenting GNUC features in the HTML docs.
What does this have to do with implicit-int, which is a constraint
violation? Where in the GNUC html documentation does it say that
constraint violations applied to Type specifiers have been carved out as
a GNUC extension?
It's not a GNUC extension, you cannot assume it will work. It might work
anyway, but that's a matter of luck.
> So I ask you again: what is unclear about declarations which are
> implicitly int, in a way that is likely to cause program errors?
It is unclear why you are overly focused on implicit-int, to be honest.
But your arguments in favor of implicit-int aren't very compelling either.
--
Eli Schwartz
Re: More C type errors by default for GCC 14
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 of the variable is `int'. > There's absolutely nothing ambiguous about it whatsoever: 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 the behavior is documented and specified as a "C Extension" for the GNUC language dialect. You've provided some excuses like "C++ is a valid language for writing documentation in, and the HTML docs are lacking", but your arguments are not convincing. 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*** means it isn't a formal GNUC language dialect extension. You can stop arguing your opinions based on what running gcc or g++ produces in the form of machine code. What gcc or g++ produces in the form of machine code is not guaranteed even across bugfix releases -- your only guarantee is that if it is documented in the ISO standards documents or in the GCC html manual, the produced machine code shall be in accordance with what the documentation says it shall do. Undefined and undocumented behavior is not a language extension. It is undefined and undocumented behavior. 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 cause it to be defined and documented, and your trust will, if you are wise, depend on you pinning an exact source code commit of the compiler. Do not depend on bugfix releases of GCC to preserve your undocumented semantics. They may or they may not, but if they don't, it's not a GCC bug, because it is ***undocumented***. ... So in answer to your question, the meaning of such a variable declaration is very much unclear -- C specifies one thing, GNUC doesn't specify *anything*, and actually executing the gcc compiler frontend tool will do... something. -- Eli Schwartz
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 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. This sounds like a "you" problem. If your Makefiles are totally incapable of respecting the user's choice of C compiler, you may need to do the same thing that you'd do to compile it with any alternative compiler: add a directory to your path containing a wrapper script called "cc" which runs /opt/tinyc/bin/tcc "$@" or aarch64-linux-gnu-gcc "$@" or whatever. Although in this case it could just call /usr/bin/gcc -fpermissive "$@" -- Eli Schwartz
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 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. Instead of adding one flag to their Makefile, which is too much work, they will add *many* declarations of `extern int foo();` across many source files in the same project? Very interesting definition of burdensome work. You keep saying "just about what anyone will do", but I do not believe this is what anyone other than you will do. > 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 reading is faulty, and your beliefs about how software work are also faulty, if you believe that the issuance of a diagnostic is what constitutes adding new features to the language dialect called "GNU C". Please start a new thread, titled something like "the documentation is flawed, which should be fixed, because implicit function declarations are referenced but not to clearly". Argue there, that implicit function declarations should be documented on the "C Extensions" page. Until everyone is on the same page as you about whether these are GNUC extensions, this conversation will go nowhere. >> 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? "no one agrees with you" is a common idiom that states that a person (in this case Po Lu) holds an opinion that rest of the world (all persons not named Po Lu) do not hold. Since you cannot agree with yourself -- you are yourself -- I am forced to believe that you are trolling by accusing me of denying you personhood. >> importantly, GCC does not agree with your analysis. > > For some definition of GCC, which is apparently you. No, just the GCC manual. >> 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'. Irrelevant, I shall ignore this comment -- it is not listed on the "C Extensions" page. >> 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: The concept of a language extension is defined by the page that says "these are the extensions to the language". Please take your mendacious reading of the C standard and put it back where you got it from. > - undefined behavior, the behavior upon use of an erroneous construct > for which the Standard imposes no requirements whatsoever. > > - unspecified behavior, where upon the use of a construct for which > the Standard imposes two or more possible behaviors, and leaves the > selected behavior unspecified. > > - implementation-defined behavior, unspecified behavior where each > implementation documents how the choice is made, and is required to > document that choice. > > If the translator precisely defines either undefined behavior (in thi
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? 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
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
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: 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. 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
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
On 5/11/23 12:46 AM, Eli Schwartz wrote: > On 5/10/23 11:56 PM, Po Lu wrote: >> And remember that `-traditional' DID exist for a certain amount of time. >> Then it was removed. So in addition to annoying a lot of people, what >> guarantees that -Wno-implicit will not be removed in the future, after >> the proposed changes are made? > > > What guarantees of the future do you have for anything? > > What guarantees do you have that a meteor won't hit Earth and wipe out > all human life in a great catastrophe? > > What guarantees do you have that GCC will still be run by the current > maintainers? > > What guarantees do you have that GCC will still be maintained at all? > > What guarantees do you have that GCC won't decide next year that they > are deleting all support for std > c89, making -traditional the default, > and becoming a historical recreation society? > > What guarantees do you have that GCC won't decide next year that they > are deleting all support for std < c23, mandating that everyone upgrade > to the very latest std that isn't even fully implemented today? > > What guarantees do you have that reality exists as you think of it? > Maybe you are a pink elephant and computers are a figment of your > imagination. > > ... > > I think that what-ifs aren't the most productive use of our time. The > current proposal provides for -std=c89 and similar, so the current > proposal does not cause current GCC users to be unable to use GCC after > the proposed change. > > If a future proposal causes current GCC users to be unable to use GCC > after the future proposal is implemented, then, and only then, should we > worry about whether it will be possible to use GCC. Then, and only then, > will a threat to prevent doing so have actually materialized. P.S. No, it is not realistic that GCC will remove support for a language feature of c89, until and unless GCC removes support for -std=c89. So I do not know why you are talking about -Wno-implicit. That isn't the question, that's not what's up for debate here. The question is whether GCC will drop support for -std=c89, with all the language functionality that encompasses (including defaulting to not issuing fatal diagnostics when you use it, or indeed issuing diagnostics at all). So please restate your question, as such: > And remember that `-traditional' DID exist for a certain amount of > time. Then it was removed. So in addition to annoying a lot of > people, what guarantees that -std=c89 will not be removed in the > future, after the proposed changes are made? -- Eli Schwartz
Re: More C type errors by default for GCC 14
On 5/10/23 11:56 PM, Po Lu wrote: > Eli Schwartz writes: > >>> Unfortunately, we do not have the source code for our compiler. Would >>> you care to ask people here to restore `gcc -traditional'? >> >> >> This would appear to be a self-inflicted wound. If I understand the >> chain of events properly... > > The chain of events actually is: > > - The code was originally written for the BSD Unix cc. > - Eventually, it started to be built with GCC, with -traditional. > - GCC removes -traditional. > - We are forced to find another C comppiler. Right, this is what I said. Although your bullet points 1 and 2 don't really have much of anything to do with it. In between points 3 and 4, I noted that you wish to *use* such bad code. I didn't say you wish to write it, merely that you wish to use it (without judging when it was written). > Note that I wasn't where I am when this started, so everything above is > second hand knowledge. > > And finally, this: > >> - to avoid making it produce invalid results, you hack your linker > > Which is essentially link-time lint, and not related to the subject at > hand. I only mentioned it to make a point, which is that people writing > traditional C in this day and age are unlikely to make any mistakes > doing so. Absolutely! It's a very good point. It's a point that people writing traditional not-C in this day and age are doing so with highly complex toolchains they have personally written to do things that no non-bespoke toolchain does. As such, they are unaffected by any and all decisions GCC makes. But if they were affected by such decisions, they would have the technical knowledge to modify GCC to suit themselves. >> You'd rather hack your compiler, but you cannot do it because you >> purchased a proprietary compiler and didn't purchase the rights to its >> source code. >> >> (BTW, there's a FOSS compiler that you can hack on if you like.) > > Which sadly does not support the code which we need to compile. > Clearly, turning GCC into a K&R compiler is not a very welcome idea > around here, so why would we hack on it? But your bespoke toolchain did not support the code which you need to compile either. That's why you began hacking on it at all, to suit your needs. So if neither GCC nor your bespoke toolchain support the code you need to compile, and you must modify *something* to suit yourself, then it is definitely possible to do it for GCC instead. I don't see what the welcome for making these modifications into the default flagship experience for the entire free software ecosystem, has to do with your being welcome to hack on GCC for your own personal use. Do you feel welcome by your proprietary vendor, who refuses to let you touch it at all by withholding source code? >> That's all fine and well, you do you. What I do not understand is, two >> things. >> >> First of all, why are you calling this "traditional C"? It is not >> "traditional C". It isn't C. It is not-C. > > When the file names for the source files end with `.c' and `.h', and the > compiler is named `cc' and `acomp', it is C. It just isn't Standard C. BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to /usr/bin/python. ... No, the criteria for whether something constitutes a given programming language are not "the file extension says so" or "the compiler name says so". A programming language is defined by the syntax and meaning of that programming language. (If we were to replace this conversation with a definition of what constitutes python, then as a scripted language, all files without file extensions could be python scripts. And similarly, people play interesting games with C files by naming them unconventional names and passing -xc to the compiler. File extension autodetection isn't everything.) >> Second of all, why is this GCC's problem? You are not a user of GCC, >> apparently. > > Because decisions arbitrarily made on GCC's part will simply result in > even more people deciding to find some other compiler. > > The point being that people sufficiently dedicated to their existing > code to not have changed in over 30 years will not respond to such > changes by changing their code. They are much more likely to look for > some other compiler instead. Well no, because if they are sufficiently dedicated to their existing code to not have changed in over 30 years then they are writing c89 code and passing -std=c89, and this is acceptable as far as GCC is concerned and their code will still compile. So they won't feel inclined to find some other compiler, and quite frankly, if they were doing the right thing in accordance with the standard way to use the language they prefer to use, then they probably will not notice that GCC changed anything? >> And implicit-function-declaration does not have the same problem as >> -traditional, because implicit-function-declaration ***WILL*** have a >> flag that permits people who are users of GCC, an
Re: More C type errors by default for GCC 14
> Unfortunately, we do not have the source code for our compiler. Would > you care to ask people here to restore `gcc -traditional'? This would appear to be a self-inflicted wound. If I understand the chain of events properly... - gcc drops support for -traditional - you wish to use code that does the badness - you purchase a proprietary compiler that permits it anyway - to avoid making it produce invalid results, you hack your linker You'd rather hack your compiler, but you cannot do it because you purchased a proprietary compiler and didn't purchase the rights to its source code. (BTW, there's a FOSS compiler that you can hack on if you like.) That's all fine and well, you do you. What I do not understand is, two things. First of all, why are you calling this "traditional C"? It is not "traditional C". It isn't C. It is not-C. Second of all, why is this GCC's problem? You are not a user of GCC, apparently. Moreover, this discussion is not about -traditional! It's about implicit-function-declaration. And implicit-function-declaration does not have the same problem as -traditional, because implicit-function-declaration ***WILL*** have a flag that permits people who are users of GCC, and just want implicit-function-declaration back. So you have exactly what you want out of this conversation. We concede. C type errors by default will come with a flag to disable them. -- Eli Schwartz
