Re: Is the GNUC dialect anything that GCC does when given source code containing UB?

[Po Lu <luangruo@yahoo.com>]

Eli Schwartz <eschwartz93@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.