Re: More C type errors by default for GCC 14
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 seriously.
We're not talking about the C Standard here. Eli S. is claiming that
gcc.info is the source of truth for the behavior of GCC, and whenever
some behavior of GCC is not documented (or contradicts the
documentation), GCC should be fixed to behave as its documentation
specifies.
> It is, after this proposal is accepted, still up to the user to decide.
> The only difference is that the default would be friendlier to new code
> and users and most code that exists today, rather than to very old code
> and incorrect code.
That's not correct. It would be as friendly to new code as it is now --
but old (and very likely still correct) code would be put at a
disadvantage.
> Additionally, there isn't enough information to compile. The compiler
> makes up new information to fill in the gaps.
According to a specific formula that all C programmers (at least, those
who write such code) know.
> If that definition accepted, most error recovery should be turned into
> valid code paths that participate as GNU extensions, for instance,
> there's no reason that:
>
>int f (int x) { x += 10 return x + 123 }
>
> shouldn't compile, as the compiler knows where to insert semicolons to
> make it (probably) work. I'd say that extension is more acceptable than
> the ones being proposed into turning into errors by default, since it
> isn't very ambiguous, unlike an implicit function declaration or such.
Unfortunately, this has never worked in any C compiler, and is very
ambiguous. Implicit int and function declarations have been included in
every ANSI and K C compiler, and then some more after that, so what
the compiler should do is very precisely specified and known.
> It has been 25 years since the addition of -fpermissive to G++. I'm
> optimistic.
But -fpermissive is considered ``useful'' by the many loud people who
find it necessary to compile C as C++.
Re: More C type errors by default for GCC 14
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, whether > intentional or accidental". That's just silly. GCC's support for implicit int is clearly intentional. I never claimed that accidental GNU CC behavior was part of GNU C. > No, Eli S. is quite right. [...] > And when the compiler is wrong and the documentation is correct, the > compiler is fixed. And the documentation is wrong, while the translator is correct. GCC development, being part of the GNU project, is supposed to act in its interests and that of Free Software in general. I remind you of of this statement, which was made here, on this list, by clearer minds: We cannot do everything all users want, and sometimes a maintainer has to say no to users. "You cannot please everyone," as the saying goes. There are many kinds of reasons which can sometimes be good reasons to say no. But maintainers should always say no reluctantly--never eagerly. We should never aggressively cause trouble for users today, just because someday it might be necessary. That is like amputating limbs because someday they might be crushed. This treatment of users brings shame on the GNU Project. I ask everyone therefore not to suggest that we should treat users this way. And yes, such shameful treatment is directly harmful to the goals of the GNU Project: at least one organization, likely more, has been forced to adopt proprietary compilers as a direct result.
Re: More C type errors by default for GCC 14
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 been generally reiterated, or even iterated. Parse error. > Repeating this statement won't make it true. Before you say this, I suggest that you take some time to look at yourself in a mirror. > 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". Where is it written that GNU CC follows your so-called ``specification-driven development''? Here is an explanation from one of the original GCC developers. It discusses strict aliasing, but the same principles apply here: (199909100634.caa01...@psilocin.gnu.org) My comment is similar to Mark's comment. Documentation, what can we document as working? We should not even try to document that these cases work. Documentation is what we do when we add a feature. I am not proposing this as a feature, just as a way to avoid evitable trouble for users. We should not even try to document a class of cases that are "supposed" to work, because I'm not saying these are "supposed" to work. We should just let them work. Anway, more questions from me than answers... Off hand though, if we can make the compiler generate `right' code in more cases, even if the users code is wrong, I think we should probably do it. 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 certain committee (which I was a member of) about what cases conforming compilers should commit to support. We must not let ourselves start thinking that C code is "wrong", just because it is not conforming ISO C code. C programs use many cases that are not conforming, but do work. This will be true for as long as C is used, because changing it would require major changes in the C language. From time to time, there is a real *need* to make some of these cases stop working, for the sake of some benefit that users want. When this happens, we should do it; the user community will accept it, because they will see that it is being done for their sake. Some will grumble, but the users who appreciate the benefits will convince them. But when there is no *need* to break these cases, when we can keep them working fairly easily, we should keep them working. If we break them unnecessarily, we invite the legitimate anger of the users. and another (199909100634.caa01...@psilocin.gnu.org): However, I have a rather serious objection: it means that users cannot tell whether their code is valid, even according to the GCC rules, without knowing the internals of the compiler. This has always been true. It is true in the current version of GCC with regard to aliasing, even when -fstrict-aliasing is used. It is part of the nature of C. The goal of trying to avoid it is unrealistic and misguided; it can't be done. So this cannot be a valid reason to reject a change. The compiler should continue to aggressively break code that misbehaves in this way. This proposes to break users' code, just to bully them into changing it. That is a callous and harsh attitude towards the users of GCC. No wonder users are angry. They know that the problems are not due to necessity, but due to callous disregard for them. We cannot do everything all users want, and sometimes a maintainer has to say no to users. "You cannot please everyone," as the saying goes. There are many kinds of reasons which can sometimes be good reasons to say no. But maintainers should always
Re: More C type errors by default for GCC 14
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 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
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.
Btw, try to compile any program using inline assembler, and you will
quickly find out how many programs depend on the (gasp!) non-conformant
behavior of GNU C.
> 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?
As I said, what the Info documentation does not say is completely
irrelevant. I might as well ask you: where in (gcc)C Extensions is it
said that the documentation describes each and every extension and
aspect of GNU C?
The documentation is supposed to describe the behavior of the
translator, not to specify it.
> It's not a GNUC extension, you cannot assume it will work. It might work
> anyway, but that's a matter of luck.
It _is_, regardless of what you might say.
> It is unclear why you are overly focused on implicit-int, to be honest.
Because there is a point to be made for discouraging implicit function
declarations. Certainly not enough to make them errors in GNU C, but
enough to justify their obsolescence in the ANSI Standard.
There is none whatsoever for discouraging implicit int. Its
obsolescence and later removal was simply the act of a overzealous
Committee, deviating too far from its task of standardizing existing
practice.
> But your arguments in favor of implicit-int aren't very compelling either.
Tell me how?
Re: More C type errors by default for GCC 14
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 the behavior is documented and specified > as a "C Extension" for the GNUC language dialect. Yes, by the definition of ``extension'' used by everyone except you. > 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. GCC documentation is written in HTML? That's news to me. I always thought it was written in Texinfo. > 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? > 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. > 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.
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 error (a violation of a "shall"
> directive).
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.
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.
So I ask you again: what is unclear about declarations which are
implicitly int, in a way that is likely to cause program errors?
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 nothing ambiguous about it whatsoever: register i; extern limit, *k, do_some_computation (); for (i = 0; i < limit; ++i) k[i] = do_some_computation (i); Please try to prove me wrong.
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 mistake? Because I don't see why it's a good idea to expect people who have just begun learning C to immediately be able to write correct code. BTW, please don't quote the parts of of an article which you are not responding to. Especially not excessively so, which you just did.
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:
> 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 being built because CFLAGS changed.
> I could only imagine someone doing this if they're being either
> extremely uninformed, extremely restricted (e.g. no change to any
> configuration files, no pragmas to disable the errors and not even
> having 10 seconds to look up the correct function prototype) or
> deliberately obtuse.
Under time restrictions, or being extremely uninformed, yes. These are
precisely the situations that many GCC users are under.
> Now you're the one playing with words. That, or you have a complete
> lack of understanding of extremely common English expressions, which
> you may want to work on as you will otherwise inevitably have large
> problems effectively communicating anything with people on this list.
That my response was so short should have made my point clear, right?
It's a tangent. I don't claim to speak for anyone other than myself,
and Eli Schwartz implied that I was.
> The "definition of GCC" used here is in a more general sense, i.e. the
> GCC project and the people involved in it that would be considered
> generally representative of it.
But we're debating behavior of the C translator itself, and the
definition of that is clear: the code which comprises the C translator,
cc1, and its frontend, gcc. What any person thinks, AFAIK, is not
really relevant.
> In fact, so far on this thread I've seen almost nobody on your side of
> the argument, save for a very few extremely loud people repeating the
> same arguments over and over.
>From my perspective, I also see only a few extremely loud people
repeating the same arguments over and over. But how many times have I
mentioned that? The number of people in this thread is too small to
conclude anything from.
> So far I've seen only a single minor GCC contributor arguing the
> behavior should be kept as-is - pretty much everyone else agrees the
> behavior should be changed. In fact, I've talked to many people who
> are not currently posting in this thread, who consider that the
> default should be changed, and are watching in consternation as a few
> people appear to be trying to hold back the entire community with
> extremely bad defaults.
In this entire thread of long winded flames, I've not heard a single
reasonable attempt to explain the following points of contention:
1. Why GCC gets to judge whether or not users' code is correct or not.
2. How implicit function declarations are different from function
declarations with no parameter specification, and why it is
reasonable to make the former an error while allowing the latter.
By extension, why implicit function declarations are ``always
wrong'', as some people have been claiming.
(Aside from, of course, that ``the Standard allows''.
But the Standard also allows implicit function declarations and
int.)
3. How implicit int makes the meaning of a program unclear, in any
way, with the exception of C2X and auto. I have not ever seen auto
explicitly used as a storage class specifier, so from my
perspective that is not really a problem.
4. Why people under various time or (mental) energy constraints will
not simply insert the necessary declarations to pacify GCC, which
will be as correct as the implicit declaration was.
> In the "C Extensions" section?
The `C Extensions' node is not the only document describing extensions
accompanying the translator.
> By the same line of argumentation, any accepts-invalid is actually not
> a bug and should instead be considered a documentation bug that should
> be fixed by altering the documentation rather than fixing the actual
> bug (given that you appear to consider that making GCC not accept code
> that it previously accepted by default is something that should never
> be done). I hope you understand that's not a reasonable line of
> argumentation.
No, because this is not a bug where GCC accepts invalid code in the
first place. This is behavior which was explicitly introduced into GCC,
but not documented in a more appropriate location in the manual.
> To be honest, I'd be inclined to consider the current behavior a
> longstanding bug that's been wrongly considered to be a WONTFIX for
> many years, and that we're only now getting around to fixing, if you
> really want to go down this line of argumentation.
Where is the ticket/thread on {Bugzilla,gnu.gcc.bug,gcc-bugs}? Anyway,
I've never argued anything to this effect. In fact, I would be more
inclined to consider the decision to not consider this a bug the
decision that explicitly defined it as behavior of the C translator.
> Actually, now that I think about it, what are you actually trying to
> get from
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, most sites would simply install such a script as `gcc', and as a result the stricter behavior would not actually reach anyone. Making it pointless, wouldn't you say?
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 whose definitions differ between systems. Especially, do not declare any prototypes for them. The implicit declaration is likely to be correct. However, I cannot find it anymore.
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 ecosystem has a shockingly bad reputation when it comes to > security and "just don't write bugs" is naive and ineffective. Maybe > you're good enough for that to work, but then you should also be able > to cope with a change in defaults. Right, and how many percent of those came from implicit function declarations? Implicit int? Extern declarations in function scope being applied at file scope? Arithmetic between floats being done as doubles? Narrow-type promotion to unsigned int? > It's time for some defaults to change so that modern C is preferred, > and "implicit everything, hope the programmer got it right" requires > explicit action, *but it's still possible to do* for the 1970s > nostalgia fans. It is impossible for implicit int to lead to bugs. > If you want to believe that's the start of a slippery slope, that's > your choice. The nostalgia club can always fork gcc if necessary, > that's one of the great things about free software. I am not part of a nostalgia club, so you might as well stop using this label. In courtrooms, the plantiffs may be precluded from using terminology that can mislead the jury. This is more or less equivalent. > GCC has always taken backwards compatibility seriously. That doesn't > mean it is the prime directive and can never be violated, but it's > absolutely always considered. In this case, changing the default seems > appropriate to many people, including those who actually maintain gcc > and deal with the consequences of the current defaults. What consequences? Really? > Do you have anything new to add other than repeating the same > arguments? We've heard them now, thanks. 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 certain committee (which I was a member of) about what cases conforming compilers should commit to support. We must not let ourselves start thinking that C code is "wrong", just because it is not conforming ISO C code. C programs use many cases that are not conforming, but do work. This will be true for as long as C is used, because changing it would require major changes in the C language. From time to time, there is a real *need* to make some of these cases stop working, for the sake of some benefit that users want. When this happens, we should do it; the user community will accept it, because they will see that it is being done for their sake. Some will grumble, but the users who appreciate the benefits will convince them. But when there is no *need* to break these cases, when we can keep them working fairly easily, we should keep them working. If we break them unnecessarily, we invite the legitimate anger of the users. and: You are arguing for a position that rejects the very idea of making an effort to keep old code working. Your arguments support a general conclusion that "If code is not unambiguously valid, it is better to break the code than to keep it working." This is not just a harsh policy, it is an explicit policy of being harsh. That is, it says, "Be harsh! Choose the alternative that is harsh!" This is the opposite of the way we should treat our users. I understand that your views are not based on sadism or cruelty; you think that treating users harshly is better for them. But your motivation, like my motivation, is not the issue anyway. To adopt a policy of harshness towards people--no matter what justification is offered for it--is treating them badly. That is the wrong way to treat the users. We must not make GCC decisions based on a policy of harshness. I would like future GCC decisions to be based on the policy that keeping old code working is a good thing to do, when it is practical of course. So if any argument leads to the conclusion that one should be harsh to the users, please recognize where the argument is taking you, and reject it on the grounds that it is a disguised policy of harshness. In particular, if it is argued that a policy of kindness has a disadvantage, and it turns out that the disadvantage is a consequence of the fact that the users have been treated kindly, it is really a disguised policy of harshness. It is sad that this mature attitude no longer seems to be prevalent among the current maintainership.
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 such an option. > they will add *many* declarations of `extern int foo();` across many > source files in the same project? Yes: it's less work. > 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. I've seen people do this. If you place yourself in the position of either a user installing a program he is unfamilar with, a user who does not know that `-fpermissive' exists, or a programmer operating under time constraints, then you will quickly find yourself doing the same thing. > 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". Which part of ``also'' do you not understand? >From n1124: A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined. Implicit int is a violation of various kinds of declaration syntax, and the Standard does not place any requirements on the behavior of the translator/implementation after the diagnostic is issued, but GCC explicitly defines how it translates such syntax. Making it an extension. > 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. Please. I ask you this: where in the manual is it described that the behavior of the compiler defers to the manual, and not the other way around? > "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. No, I'm simply describing that you speak for yourself, and nobody else. Just like I do. > No, just the GCC manual. See above. > Irrelevant, I shall ignore this comment -- it is not listed on the "C > Extensions" page. And where does the manual say that (gcc)C Extensions node is the only document describing extensions to the language implemented by the GNU C translator? > 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. How is my reading of the Standard incorrect? >> - 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 this >> case, erroneous syntax) or unspecified behavior, then that definition is >> commonly considered to be an extension of that translator. Nothing >> gcc.info says will change that. > > > ... because the GNUC language dialect is not synonymous with either > undefined, unspecified, or implementation defined behavior. Quoting > random definitions of things that aren't "C Extensions" don't make them > C Extensions. Erroneous constructs leading to the issuance of a diagnostic message are undefined behavior. > I also find it difficult to understand how adding a diagnostic telling > you not to do something would be synonymous with "precisely defines" > doing that thing. There's nothing precise about it? Because translation proceeds as if: register k, j; was: register int k, j; and: gettimeofday (, 0L); proceeds as if: extern int gettimeofday (); was placed above `gettimeofday' at (I believe) file scope. I don't see how this could be any less precisely defined. > "Nothing gcc.info says will change that". What? Please tell me how this > can be so. What
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 be as portable as possible (naturally, since Autoconf does not configure for the build machine). As a result, they are typically written in the subset of ANSI C that will compile with almost any C compiler, which is exactly what will cause problems with GCC's proposed new defaults.
Re: More C type errors by default for GCC 14
Eli Schwartz writes: > There are ***not*** thousands of Makefiles that have this issue. But if > there were, then Makefiles are very easy to update, and only have to be > updated once per project, not thousands of times. So this is fine. You > may have to update your Makefile, but that is no big deal. > > It's still no big deal, no matter how much you dramatize the intensity > of adding a flag to your Makefiles. It's extra work. Why don't I just write: extern int foo (); above each of the new errors? That is just about what anyone will do when confronted by these new errors. As a result, you have not ensured that any declarations are correct, but instead you have annoyed a lot of people and lulled yourself into a false sense of safety. > So you concede that GCC is not telling you, only trying and failing to > tell you? I concede that you're playing with words. > Great, so what's the problem? If GCC can't actually enforce it, and even > goes out of its way to offer you options to ignore what it's telling you > to do, then maybe... > > ... it's not telling you what to do with your code, only suggesting what > to do? > > So ignore the suggestion. Which is made annoying, especially when there is absolutely NO guarantee being made that the new option will stay. > I'm not sure what this semantics game here is trying to say. Is it > ethically and morally wrong for GCC to try to tell you what to do with > your code? Is it undignifying to have a mere machine go and lecture you, > a real human being with a consciousness and free will, what to do? > > Because if that's what this is about then I think you are taking this > inanimate object way too personally. > > If not, then I am simply entirely unsure what your objection is to being > "told". > > >>> Because that's exactly what is going on here. Features that were valid >>> C89 code are being used in a GNU99 or GNU11 code file, despite that >>> ***not*** being valid GNU99 or GNU11 code. >> >> How GCC currently behaves defines what is valid GNU C. > > > No. Absolutely positively 100% no under any circumstances whatsoever no. > > This has been explained multiple times by the GCC developers. e.g. > search for references to accepts-invalid. > > """ > They are bugs where compiler accepts something that isn't valid in > the selected language nor considered valid extension. > So, after the fix we reject something that has been accepted before. > > In the last few years (checked what was fixed in 10/11/12/13 releases so > far), we've fixed 12 such bugs explicitly marked that way: > """ The Standard states that each conforming implementation must be accompanied by a document which documents each and every extension. This document is the GCC manual, which makes reference (not too clearly, however, which should be fixed) to both implicit int and implicit function declarations, which are allowed in C99 and later dialects of C. These constructs are not bugs. These constructs explicitly defined by GNU C; since a diagnostic is issued, GNU C's implementation also conforms to the Standard. > You cannot, and are not permitted, to define "how GCC currently behaves" > as "defines what is valid GNU C". No one agrees with your analysis. Most ^^ I'm not a person? > importantly, GCC does not agree with your analysis. For some definition of GCC, which is apparently you. > It's a wild, wild, wild claim to begin with. You are arguing that any > bug, ANY bug whatsoever, which qualifies for the title "how GCC > currently behaves" because if a bug is currently present, then GCC > currently behaves in a buggy manner... > > ... any such bug is, ***because*** GCC currently does it, now part of > the documentation on "GNU C", a language dialect with documentation. > > Can you show me where on > https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC > documentation states that "C Extensions include anything that GCC > currently does, no matter what, no matter how documented or undocumented"? I see: `-Wno-implicit-int (C and Objective-C only)' This option controls warnings when a declaration does not specify a type. This warning is enabled by default in C99 and later dialects of C, and also by `-Wall'. `-Wno-implicit-function-declaration (C and Objective-C only)' This option controls warnings when a function is used before being declared. This warning is enabled by default in C99 and later dialects of C, and also by `-Wall'. The warning is made into an error by `-pedantic-errors'. > The concept of a language extension has bulletproof meaning. You cannot > get around it, redefine it, pretend that something is when it isn't, or > otherwise disagree with this bulletproof meaning. The concept of a ``language extension'' is not defined anywhere. Instead, there are three kinds of behavior not precisely specified by the Standard: - undefined behavior, the behavior upon use of an erroneous
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/gnu11 and if they're doing that, they shouldn't be getting > something which was removed from the C standard. But if they really want > it, they can either downgrade to C89 (rather drastic), or set the > proposed -fpermissive. Too much trouble. Let me tell you what will actually happen: people will never do what you want them to. Instead, they will simply write: extern int foo (); above the new errors. As a result, you will not have really accomplished anything other than making a lot of users angry. The declarations will continue to be as correct as they have always been.
Re: More C type errors by default for GCC 14
Sam James writes: > And I would not want to see that happen either, nor do I think Florian > would, or many of the other participants in this thread. > > Indeed, for some projects, where it's hopeless^Wlots of work, > we're using -std=c89 or -std=gnu89 as appropriate - as already stated. > > But most things are easy to fix. > > Our interest is purely in making the default stricter for better UX, > reducing the net amount of these bugs in the wild, and avoiding > regressions when we fix these problems. Trying to remove C89 entirely > would, if nothing else, be needlessly antagonistic, but some of the > replies seem to act as if we have. But programs are not using c89 or gnu89, right? They are using gnu99 and gnu11.
Re: More C type errors by default for GCC 14
Eli Schwartz writes: > Except this thread is not arguing to remove support for -std=c89 as far > as I can tell? > > The argument is that on newer values for -std (such as the one GCC > defaults to if no -std is specified), GCC should adapt its diagnostics > better for the std in question. These newer -stds should stop issuing a > warning diagnostic, and begin issuing an error diagnostic instead. > > The latter group most certainly does have somewhere to go other than > proprietary compilers -- it can go to GCC with -std=c89 (or -Wno-* or > -fpermissive or -fold-code or whatever the case may be). > > But I do not understand the comparison to -traditional. Which was > already removed, and already resulted in, apparently, at least one group > being so adamant on not-C that it switched to a proprietary compiler. > Okay, understood. But at this point that group is no longer users of > GCC... right? Yes. > So what is the moral of this story? To avoid repeating the story of > -traditional, and instead make sure that users of -std=c89 always have a ^^ > flag they can use to indicate they are writing old c89 code? > > If so, then as far as I can tell, that was the original plan? The flag > already exists, even. And the original proposal was to provide another > flag that doesn't even restrict you to c89. And what will guarantee this ``always'' always remains true?
Re: More C type errors by default for GCC 14
Eli Schwartz writes: > This discussion thread is about having very good technical reasons -- as > explained multiple times, including instances where you agreed that the > technical reasons were good. > > Furthermore, even despite those technical reasons, GCC is *still* > committed to not breaking those old programs anyway. GCC merely wants to > make those old programs have to be compiled in an "old-programs" mode. > > Can you explain to me how you think this goal conflicts with your goal? Because now people will have to go through dozens and dozens of Makefiles, configure.in, *.m4, just because GCC made a decision that results in everyone inserting: extern int foo (); above what used to be implicit function declarations?
Re: More C type errors by default for GCC 14
Arsen Arsenović writes: > Indeed they should be - but warning vs. error holds significance. A > beginner is much less likely to be writing clever code that allegedly > uses these features properly than to be building new code, and simply > having made an error that they do not want and will suffer through > confused. Most programs already paste a chunk of Autoconf into their configure.ins which turns on more diagnostics if it looks like the program is being built by a developer. i.e. from Emacs: AC_ARG_ENABLE([gcc-warnings], [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@], [control generation of GCC warnings. The TYPE 'yes' means to fail if any warnings are issued; 'warn-only' means issue warnings without failing (default for developer builds); 'no' means disable warnings (default for non-developer builds).])], [case $enableval in yes|no|warn-only) ;; *) AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;; esac gl_gcc_warnings=$enableval], [# By default, use 'warn-only' if it looks like the invoker of 'configure' # is a developer as opposed to a builder. This is most likely true # if GCC is recent enough and there is a .git directory or file; # however, if there is also a .tarball-version file it is probably # just a release imported into Git for patch management. gl_gcc_warnings=no if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then # Clang typically identifies itself as GCC 4.2 or something similar # even if it is recent enough to accept the warnings we enable. AS_IF([test "$emacs_cv_clang" = yes], [gl_gcc_warnings=warn-only], [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])]) fi]) So this is really not a problem. > Indeed. I said facilitates, not treats equally. I think the veterans > here won't lose much by having to pass -fpermissive, and I think that's > a worthwhile sacrifice to make, to nurture the new without pressuring > the old very much. Until `-fpermissive' goes the way of `-traditional', `-fwritable-strings'. > On that note - lets presume a beginners role. I've just started using > GCC. I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out. It > mentions some 'implicit function generation', dunno what that means - if > it mattered much, it'd have been an error. I wrote a function called > test that prints the int it got in hex, but I called it with 12.3, but > it printed 1.. what the heck? Have you actually seen anyone make this mistake? > Why that happened is obvious to you and I (if you're on the same CPU as > me), but to a beginner is utter nonsense. > > At this point, I can only assume one goes to revisit that warning.. I'd > hope so at least. > > I doubt the beginner would know to pass > -Werror=implicit-function-declaration in this case (or even about > Werror... I just told them what -Wall and to read the warnings, which > was gleefully ignored) I'd expect a question from the newbie, directed at a web search engine. > Hell, I've seen professors do it, and for a simple reason: they knew how > to write code, not how to use a compiler. That's a big gap. > > The beginner here can't adapt - they don't know what -Wall means, they > just pass it because they were told to do it (if they're lucky!). If this is really such a bad problem, then how about clarifying the error message? > At the same time, they lose out on what is, IMO, one of the most useful > pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables > it by default.. we do). It provides effective bug detection, when the > code compiles right. It regularly spots bugs that haven't happened yet > for me. > > (and same goes for all the other useful analysis the toolchain can do > when it has sufficient information to generate correct code, or more; > some of which can't reasonably be a default) > > (on a related note, IMO it's a shame that the toolchain hides so many > possibilities behind 'cult knowledge', depths of many manuals and bad > defaults) _FORTIFY_SOURCE is not really important enough to be considered here. It's not even available everywhere. > This sample is subject to selection bias. My testing targets mostly > more modern codebases that have long fixed these errors (if they have > active maintainers), and exclusively Free Software, so I expect that the > likelyhood that you'll need to run `export CC='gcc -fpermissive' > CXX='g++ -fpermissive'` goes up the more you move towards old or more > corporate codebases, but, for a veteran, this is no cost at all. > > Is it that much of a stretch to imagine that a maintainer of a codebase > that has not seen revisions to get it past K practices would > know that they need to pass -std=c89 (or a variant of such), or even > -fpermissive - assuming that they could even spare to use GCC 14 as > opposed to 2.95?
Re: More C type errors by default for GCC 14
Eli Schwartz writes:
> I expect no such thing, but I do expect that people making decisions in
> the real world acknowledge that ***they*** (and no one else) made those
> decisions of their own volition.
>
> I am unsure what "decisions made in the real world" has to do with my
> observation that this real-world decision was a decision to invest time
> and effort and money in one direction rather than another direction --
> and the rejected other direction was the one that would make them users
> of GCC who are affected by GCC decisions.
The point is, we chose not to modify GCC for various reasons, and the
changes being proposed here will cause more people to make this choice.
> I do not consider that you are being told what to do with your code.
> Your code is not being broken. You may have to update your Makefile to
My code is being broken. There are thousands of Makefiles, Autoconf
files containing configure tests, and so on.
> add a flag that turns off a changed default, but that does not
> constitute being told what to do with your code, only being told what to
> do with GCC.
That's GCC trying to tell me what to do with my own code.
> Very well then, (lots of) C++ is C.
>
> But many people do in fact argue that missing function declarations do
> not, in fact, look like C. It doesn't compile in a C compiler (using
^^
% cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31
% cc -Xs -Werror hello.c -o hello
% ./hello
hello world
the time is: 1683856188
% cat hello.c
struct timeval
{
long tv_sec;
long tv_usec;
};
main ()
{
struct timeval tv;
printf ("hello world\n");
if (gettimeofday (, 0L))
exit (1);
printf ("the time is: %ld\n", tv.tv_sec);
}
%
> -Werror) either. Some of the warnings under discussion in this thread
> were never valid *anywhere*.
Really? Is that, or is that not, a C compiler?
> Some people like writing some code in one language version, and some
> code in another language version, and doing so in the same file or
> perhaps even the same function. Acknowledged. I would personally be
> afraid to do that, it seems incredibly dangerous even if in the highly
> specific case of implicit function declarations it happened to work.
>
> Because that's exactly what is going on here. Features that were valid
> C89 code are being used in a GNU99 or GNU11 code file, despite that
> ***not*** being valid GNU99 or GNU11 code.
How GCC currently behaves defines what is valid GNU C.
> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
> make it a GNU extension. It compiles with a warning in c11 mode too,
> does that make it a c11 extension? No it does not.
Except it does? Since the compiler is defining behavior that is
otherwise undefined (i.e. the behavior of a program after a diagnostic
is emitted after encountering an erroneous construct), it is defining
an extension.
> I am not dictating anything to you or anyone else in this paragraph,
> though? All I said was that if one writes a c89 program and tells the
> compiler that, then they will not even notice this entire discussion to
> begin with.
>
> What, precisely, have I dictated?
That people who are writing GNU C code should be forced to rewrite their
code in ANSI C, in order to make use of GNU C extensions to the 1999
Standard.
> Have I dictated to you that a c89 program can be described to the
> compiler by use of the -std=c89 flag? This seems to be a pretty standard
> understanding, to me.
No, see above.
> Correction: I am arguing by analogy that your statement: "what
> guarantees that -Wno-implicit will not be removed in the future" is
> arguing to absurdity.
The reason I asked for such a guarantee was that two important options
were in fact removed by the GCC developers in the past: -traditional and
-fwritable-strings. So there is not exactly a good track record of
keeping useful options around, after features are made into those
arguments.
> Many people write strictly conforming program, and consider lack of
> conformance to be a coding error that must be fixed. It seems like a
> wise endeavor, frankly. I am not sure why you are challenging me to do
> so as though you think that I will be incapable of it and therefore be
> forced to concede that toggling the default diagnostic for very old code
> is a bad idea.
Really? So how many programs work when int is 16, 36, or 40 bits wide?
How many programs work when signed char has trap representations?
How many programs when char not 8 bits?
How many programs assume pointers can be converted into an integer type
without any loss of information? How many programs assume that
pointers have only one possible integer representation? (think lookup
tables using pointers to objects as keys)
How many programs assume NULL is all-bits-zero? IOW, that this
initialization makes sense:
struct foo
{
void *ptr;
Re: More C type errors by default for GCC 14
Arsen Arsenović writes:
> Seems that the algorithm and I agree. I don't see any use in the int()
> guess that the compiler does, besides accepting old code (which makes it
> candidate for -fpermissive).
I believe:
extern int foo ();
covers at least 50% of all C functions, since they are generally defined
to return int (as an error indication) with no narrow types in any
prototyped parameter list. That's a reasonable enough guess.
> We can diagnose these without invoking expensive machinery, unlike
> mismatched declarations.
How so? Remember that `extern int foo ()' declares a function with no
parameter specification returning int.
Thus, it could mean either:
foo (a, b)
char *a;
long b;
or
foo (x, y)
double x;
double y;
or perhaps even
foo (va_alist)
va_dcl
The function may even be defined with a prototyped parameter list, as
long as said parameter list does not contain any narrow types which are
subject to default argument promotions.
> I don't see why these not being diagnosed by default makes erroring on
> the far simpler implicit case not valuable (even if it leads to people
> just consciously inserting wrong declarations - that means they
> acknowledged it and made a poor decision).
All this will lead to is people making what you deem to be a ``poor''
decision. Especially if the people who have to solve the build problems
are not the original author(s) of the program being built.
> They can be caught in multiple places when obvious, such as when not
> done explicitly. These are two different errors.
An implicit function declaration is NOT an obvious error. It simply may
be an error. What is the error here?
a (b, c)
long c;
{
return pokeaddr (c, b * FOO);
}
/* in another translation unit */
b ()
{
a (1, 0L);
}
GCC is not a judge of other people's code, and shouldn't try to be one.
> I can't say. I don't have memory of the traditional mode outside of
> cpp.
-traditional tried to make GCC a K compiler. It wasn't completely
K, but it worked well enough for most cases. There,
- `extern' definitions take effect even outside the scope in which
they are declared.
- typeof, inline, signed, const and volatile are not recognized.
- unsigned narrow types promote to unsigned int.
- string constants are always writable. (BTW, -fwritable-strings
was also removed, so you can see why I'm sceptical about
any commitment to `-fpermissive' if it is ever introduced.)
- register allocation is not performed within functions that call
setjmp.
- bit-fields are always unsigned.
- single precision floating point arithmetic is carried out in
double precision.
- __STDC__ is not defined.
> The changes proposed today, however, are a few bits of entropy
> relevant in a few places - the overhead is low.
Yet it's rather pointless, as I explained above.
> It's not, though. That's why this is being conversed about. Even
> highly diligent people miss these (and even not-so-diligent people like
> me do - I've had more of these found by me passing -flto than I did by
> remembering to use an extra four -Werror=... flags, and that, of course,
> misses the int(...) case - which is not a useful one, usually what I
> meant there was (void), but strict-prototypes are a story for another
> day or year).
I can't say I've seen any such errors myself. Perhaps people should be
told to run lint instead, whose sole job is to prevent these errors from
happening?
Re: More C type errors by default for GCC 14
Jonathan Wakely writes: > On Thu, 11 May 2023 at 09:31, Po Lu wrote: >> (BTW, I thought implicit int was being discussed, not implicit >>function declarations, but here goes.) > > Then you're not paying attention, the very first mail in the thread > starts by saying: > > TL;DR: This message is about turning implicit-int, > implicit-function-declaration, and possibly int-conversion into errors > for GCC 14. It says right there that implicit-int is being discussed. I missed the part about implicit function declarations. > Please educate yourself about the topic. Evidently (from the rest of my follow-up), I already did.
Re: More C type errors by default for GCC 14
Arsen Arsenović writes: > Relying on human scrutiny when an algorithm can trivially deduce an > answer more quickly and more reliably (because even in the case that the > code you showed compiles, it assumes processor specific facts) has > historic precedent as being a bad idea. The algorithm in question is not much of an algorithm at all. Rather, it makes the blanket assumption that the lack of an explicit declaration means the implicit declaration is incorrect, and that there is a correct declaration in a header file somewhere. That sounds rather premature, don't you agree? > I'm curious, though, about how lint checks for this. Lint generates a lint library describing (among others) a description of each function definition in every translation unit it checks. It also imports pregenerated lint libraries, such as those for the C and math libraries. All declarations are then checked against the lint libraries being used. > So be it. The edge case still exists. The normal case that I expect > most code is dealing with is much simpler: a missing include. That case > is not discounted by the existence of misdeclarations across TUs. I can't believe that the normal case is a missing include, because I see `extern' declarations outside header files all the time (just look at bash, and I believe one such declaration was just installed in Emacs.) And how does that discount what I said people will do? They will get into the habit of placing: extern int foo (); above each error. Such declarations are also much more common than implicit function declarations, and are more likely to lead to mistakes, by the sole virtue of being 100% strictly conforming Standard C that need not lead to any diagnostics, and thus, extra scrutiny from the programmer. The point is, such checks are the job of the linker and lint, because as you yourself have observed, those are the only places where such bugs can really be caught: > There's already -Wlto-type-mismatch. It has spotted a few bugs in my > own code. [...] > Yes, indeed. And code should keep working on those machines, because it > costs little to nothing to keep it working. And it will if you pass > -fpermissive. And what prevents -fpermissive from being removed in the future, once the folks here decide that -fpermissive must go the way of -traditional? > It is unfeasible for GCC to entirely stop compiling this code, there's > nobody that is advocating for doing that; however, the current default > of accepting this code in C is harmful to those who are writing new > code, or are learning C. I expect people who write new code to pay even more scrutiny to diagnostics from their C translator than usual, so the existing strategy of issuing warnings should be sufficient. > Have a lovely day. You too.
Re: More C type errors by default for GCC 14
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. I'm not allowed to show any real code. > This is, at best, a "works by coincidence", rather than being code > anyone should be writing. See what I said about being the judge, jury and executioner. (BTW, I thought implicit int was being discussed, not implicit function declarations, but here goes.) The same problems will appear with _any_ extern declaration. If you remove implicit function declarations, people will simply paste: extern int foo (); above the code which no longer compiles. Or, if you force everyone to use prototypes, extern int foo (char *); You will not be able to diagnose whether or not this declaration is correct, because the definition will lie in another translation unit. Except that in this case, no diagnostic will be issued at all when the declared function is called. The only place where you can truly fix mismatched declarations is the linker (or collect2?) GCC proper cannot do anything about it. > Such code is already written, when building it, pass -fpermissive. > You benefit from the error otherwise. > > (and no, this isn't an issue of style, the code in question *does not* > convey sufficient information for the compiler to always do the right > thing) It does on reasonable machines for which the code was written. I gave two examples. Perhaps the 386 is another.
Re: More C type errors by default for GCC 14
Arsen Arsenović writes: > None of these result in a whisper-level warning before a severe but > difficult to detect breakage. Really? Why not run lint? Besides, how is this any different from allowing people to write: extern int foo (); or perhaps even extern int foo (struct bar *, long double _Complex); when foo is something else? > All of the features in question actively break programs (because they > allow entirely wrong code to be emitted). And they can also be used correctly. GCC cannot tell the difference. So why act as the judge, jury and executioner all rolled into one? > It is. It is not.
Re: More C type errors by default for GCC 14
Eli Schwartz writes: > 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). Because in the real world, almost nobody writes strictly conforming ANSI C. Some people do want to mix declarations with statements. Some people do want non-local goto, typeof, zero length arrays, arithmetic on void pointers, asm volatile, and so on. And at the same time, they also want to be able to use features such as various declarations with only a storage class specifier. All of which are presently implemented by GCC.
Re: More C type errors by default for GCC 14
Eli Schwartz writes: > 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). [...] > 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. > 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! > 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 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. > 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. > 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? What gives you the right to dictate what the Right Thing is and what is not? > 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. You are arguing to absurdity. > 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
Re: More C type errors by default for GCC 14
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. 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. > 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 compiler is not a very welcome idea around here, so why would we hack on it? > 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. > 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. > 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. 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?
Re: More C type errors by default for GCC 14
Jonathan Wakely via Gcc writes:
> On Wed, 10 May 2023, 03:32 Eli Zaretskii, wrote:
>
>>
>> And then people will start complaining about GCC unnecessarily
>> erroring out, which is a compiler bug, since there's no problem
>> producing correct code in these cases.
>>
>
>
> What is the correct code for this?
>
> void foo(int);
> void bar() { foo("42"); }
>
> Why should this compile?
Because keeping that from compiling will also keep this from compiling:
bar ()
{
extern foo ();
return foo ("42");
}
> You keep demanding better rationale for the change, but your argument
> amounts to nothing more than "it compiles today, it should compile
> tomorrow".
And so it should. Because for every invalid piece of code you can think
of, there are hundereds or thousands of combinations that may as well be
valid. For example, on the 68020, vax, or similarly reasonable 32-bit
machine:
foo (ptr)
{
register char *str;
str = ptr;
/* do stuff with str */
puts (str);
}
/* In another translation unit. */
bar ()
{
foo ("42");
}
Re: More C type errors by default for GCC 14
jwakely@gmail.com (Jonathan Wakely) writes: > No, the proposed changes are to give errors (instead of warnings) for > rules introduced in C99. GCC is just two decades late in enforcing the > C99 rules properly! The Standard requires that a diagnostic be issued upon encountering certain kinds of invalid constructs. Warnings are diagnostics.
Re: More C type errors by default for GCC 14
Sam James writes: > I think the group of people dedicated enough to patch their linker would > be able to pass a flag to the compiler to allow old constructs. Unfortunately, we do not have the source code for our compiler. Would you care to ask people here to restore `gcc -traditional'?
Re: More C type errors by default for GCC 14
Sam James writes: > Nobody here is suggesting that the ability to compile this code at > all would be removed. Throughout this thread, people discuss methods > like e.g. adding -fpermissive to allow it. Here, I'm saying that making it annoying to compile such code is not going to convince people to change the way they write. Making it impossible to do so will make them look for some other C compiler. So you might as well not try.
Re: More C type errors by default for GCC 14
Sam James writes: > No, we're talking about "things which ISO C made invalid in 1999, but > GCC kept supporting for a while". We're discussing terminating that > support. The "standard" part here is not about deference to the standard > and claiming extensions can never be made, but rather that we're keeping > something which was explicitly removed. Which is still an extension to the Standard, and a perfectly conforming one at that. The same could not be said about the lack of trigraphs, and keywords such as `asm'. > These aren't things which were in the standard and then got removed > because of how terrible they are. They're things that are considered > a part of GNU C as proper GNU extensions. Once the Standard removed those features, the implementations in GNU C became GNU extensions. No amount of wordplay is going to change that. In C99 and later dialects of C, GCC even issues a diagnostic upon encountering implicit function declarations or implicit int, thereby satisfying that requirement of the Standard. > Note that, per the rest of the thread, the constructs we're discussing > here to be banned are not considered "proper GNU extensions". Really? It is an implementation extension, the implementation being GNU C. It also seems rather arrogant to assume that you have the privilege to ban others from writing code in a certain way.
Re: More C type errors by default for GCC 14
jwakely@gmail.com (Jonathan Wakely) writes: > So let's do it. Let's write a statement saying that the GCC developers > consider software security to be of increasing importance, and that we > consider it irresponsible to default to accepting invalid constructs in the > name of backwards compatibility. State that we will make some changes which > were a break from GCC's traditional stance, for the good of the ecosystem. I'm sorry you think that way. > Given recent pushes to discourage or outright ban the use of memory-safe > languages in some domains, I think it would be good to make a strong > statement about taking the topic seriously. And not just make a statement, > but take action too. > > If we don't do this, I believe it will harm GCC in the long run. The vocal > minority who want to preserve the C they're used to, like some kind of > historical reenactment society, would get their wish: it would become a > historical dead end and go nowhere. Vocal minority? Do you have any evidence to back this claim? What I see is that some reasonable organizations have already chosen other C compilers which are capable of supporting their existing large bodies of C code that have seen significant investment over many years, while others have chosen to revise their C code with each major change to the language. The organizations which did not wish to change their code did not vocally demand changes to GCC after GCC became unsuitable, but quietly arranged to license other compilers. Those that continue write traditional C code know what they are doing, and the limitations of traditional C do not affect the quality of their code. For example, on the Unix systems at my organization, the SGS is modified so that it will not link functions called through a declaration with no parameter specification with a different set of parameters than it was defined with. Naturally, the modified linker is not used to run configure scripts.
Re: More C type errors by default for GCC 14
dje@gmail.com (David Edelsohn) writes: > This seems to be the core tension. If developers cared about these issues, > they would enable appropriate warnings and -Werror. > > The code using these idioms is not safe and does create security > vulnerabilities. And software security is increasingly important. Oh please. By this definition, every bug is a security issue. What bugs have been caused by implicit int? > The concern is using the good will of the GNU Toolchain brand as the tip of > the spear or battering ram to motivate software packages to fix their > problems. It's using GCC as leverage in a manner that is difficult for > package maintainers to avoid. Maybe that's a necessary approach, but we > should be clear about the reasoning. Again, I'm not objecting, but let's > clarify why we are choosing this approach. You will simply make life annoying for people who already have working code. People do not like it when others do that! If you make it too annoying to turn off the new diagnostics, you will not convince people who have not stopped writing traditional C code to stop doing so. Instead, they will use an older version of GCC, or license a proprietary compiler which allows them to keep writing use language as they always did. My organization eventually chose the latter when GCC removed `-traditional', and to this day we continue to write code which relies on float arithmetic being promoted to double, unsigned narrow types being promoted to unsigned int, and string constants being writable.
Re: More C type errors by default for GCC 14
jwakely@gmail.com (Jonathan Wakely) writes: > This isn't "be like Clang", this is "diagnose things that have been > invalid C since 1999". Only if your definition of valid C is ``strictly conforming to the ISO Standard''. I doubt there are many programs which fit such a definition. And anyway, GCC accepts many other constructs which can not be used in a strictly conforming Standard C programs. For example, the use of dollar signs in identifiers. Should we not also reject those, identifier names with external linkage longer than thirty two characters, hex floats, arithmetic on void pointers, zero-length arrays, statement expressions, and so on? > Accepting invalid code by default is a disservice to users. Those who > need to compile invalid C code can use an extra option to allow it, > the default should be to tell users their code is doing something bad. The code is conforming, it simply relies on extensions to the Standard. Implicit int does not break any strictly conforming program, so a C implementation implemented it continues to be conforming, along with those programs relying on implicit int. See this wording in the Standard: A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program. You are not trying to reject non-conforming C code. You are, for better or worse, trying to impose your personal preferences on users of GCC. Let's debate the real problem at hand instead of using the Standard as a boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a good idea.
