gcc prototype oddity

[Larry I Smith]

(By the way, I'm fairly certain GNU does not have a WEB site. WEB
is Knuth territory. GNU may very well have a website, or a site on
the WWW.


-Arthur

Hmm, here's the result of a google 'define:WEB site' search:

"A collection of "pages" or files linked together and available on the
World Wide Web. Web sites are provided by companies, organizations and
individuals."

"WEB site" or "website", six of one and a half-dozen of the other.

If it's the uppercase (i.e. WEB) that you're addressing, it's
a habit because that's how it must be in all documentation
written at my place of employment - per the "Documentation Police"

Regards,
Larry

 

[Allin Cottrell]

I do: changing line 3 didn't affect the relatioship between line 1 and 2
in *any* way, did it?

I think you are (unusally) being obtuse here. I was not surprised that
the gcc diagnostic disappeared when line 3 was deleted for the simple
reason that, without line 3, the program was correct -- and I respect
gcc sufficiently that I do not generally expect it to emit diagnostics
for correct C programs.

Your rejoinder -- namely, that the deletion of line 3 does not alter
the relationship between lines 1 and 2 -- is beside the point, which
was, to restate it one more time, that an inconsistency in the full
program between lines 1 and 3 was misleadingly flagged by gcc as
an inconsistency between lines 2 and 3.

Allin Cottrell

 

[Dan Pop]

I think you are (unusally) being obtuse here. I was not surprised that

I don't. See below.

the gcc diagnostic disappeared when line 3 was deleted for the simple
reason that, without line 3, the program was correct -- and I respect
gcc sufficiently that I do not generally expect it to emit diagnostics
for correct C programs.

OTOH, do you expect it to emit *bogus* diagnostics for incorrect programs,
when then mistake occurs *later* than the diagnosed line? Note, that,
in the program under discussion, there was no conflict between lines 2 and
3.

Your rejoinder -- namely, that the deletion of line 3 does not alter
the relationship between lines 1 and 2 -- is beside the point, which
was, to restate it one more time, that an inconsistency in the full
program between lines 1 and 3 was misleadingly flagged by gcc as
an inconsistency between lines 2 and 3.

It is a matter of how you interpret the diagnostic in question:
as complaining about an inconsistency between lines 1 and 2
or as complaining about an inconsistency between lines 2 and 3.
The diagnostic being "prototype declaration", and pointing to line 2,
it only makes sense to treat it as complaining about the relationship
between lines 1 and 2 (there is no prototype declaration in either
line 2 or line 3).

Dan

 

[Dave Thompson]

[gcc message pointing to wrong 'prototype' for declaration conflict]

I guess my question is, where do conformance issues end and QoI issues
begin? You say, "the original code *required* at least one diagnostic
and got it". True, but what if the diagnostic had been:

test.c:666: error: elephants are trampling your begonias

QoI takes over pretty early. Dan (probably deliberately) restated in
passing the Standard's requirement, from (C99) 5.1.1.3p1:
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. Diagnostic messages
need not be
produced in other circumstances.8)

same in C89 except for the "even if" clause, which actually seems to
be superfluous; and referring to footnote 8 or 6 respectively, but
footnotes are not normative:
The intent is that an implementation should identify the nature of,
and where possible localize, each
violation. Of course, an implementation is free to produce any number
of diagnostics as long as a
valid program is still correctly translated. It may also successfully
translate an invalid program.

Thus diagnostics are not *required* to identify or describe the error,
or even to be one per detected error; a compiler with the (in)famous
'ed' behavior of simply printing a single question mark '?' for any
error or combination of errors would be conforming, at least in that
respect; and moreover since an implementation may produce any
diagnostics it likes beyond the required one(s), a compiler that
printed a single question mark for every sourcefile, with errors or
without, would also be conforming, but perverse. Even if both beer and
speech free it wouldn't attract or deserve many users.

Your particular example warning is therefore conforming; but for me
useless since I happen not to have any begonias -- so it would
intrigue me what -W flag gcc would use to disable (or enable?) it:
maybe -W[no-]pachyderm-deflorestation ?-)

- David.Thompson1 at worldnet.att.net