Eli Schwartz <eschwart...@gmail.com> 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. What precisely defines the behavior if not the manual? The C translator itself. > Defining something is to create a description of that thing. English > language prose is the standard for creating descriptions. That's the > documentation. What else are you looking at here? C++ is no less suitable for this purpose, especially when the English language description seems to be missing. > Why does C++ compile with `gcc` as long as it has the right heuristic > file extension? > > Why is __GNUC__ defined when you specifically ask for -std=c89, which is > not -std=gnu89? Because it's specifically allowed by the Standard? All predefined macro names shall begin with a leading underscore followed by an upper-case letter or a second underscore. > I assume because the compiler is kind and forgiving, and will often > allow you to mix dialects even though you shouldn't, if it can be done > safely and without conflicting other stds. ??? > But implicit-function-declarations cannot be done safely. Really? Why? Now you're really speaking for yourself, and yourself alone. So please explain how you arrived at this conclusion. > This discussion is going nowhere until you accept that GNUC has a > definition and that definition is separate from "what GCC does when > given UB". Oh, I do recognize that difference. Conversely, you seem not to have recognized the difference between behavior that is explicitly defined by GNU C, in c-decl.c, and behavior that GNU C does not define at all, such as the result of dereferencing a pointer to NULL.
