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 (&tv, 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. Wha
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
