🚀 go-pugleaf

In article <C04EEM.4K@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
+An e-mail correspondant advised that GCC's -pedantic-errors option is virtually
+(if not actually) documented as yielding a non-conforming implementation.

Here is the description of that option from the GCC 2.0 manual:

	-pedantic	Issue all the warnings demanded by strict ANSI
			standard C; reject all programs that use forbidden
			extensions.

	-pedantic-errors
			Like -pedantic except that errors are produced
			rather than warnings.

I believe that the word "warning" is being misused in these statements, and
that we should imagine that the word "diagnostic" had been used instead.  I
believe that this reflect Richard Stallman's true intent.

Now let me briefly respond to a few of Norman's other points.  (My last
response below contains some potentially interesting fodder for the *real*
language lawyers out there.)

+----------
+Ron Guilmette:
+>#7)  When compiling an empty source file while the -pedantic-errors option
+>     is in effect, GCC will generate an error message for a line number which
+>     does not actually exist in the source file.  (The line number indicated

This is not a standards comformance issue, and so I will belabor it no further
in this forum.  I should never have raised it here in the first place.

+----------
+Ron Guilmette:
+>For any such test case that you may devise, a standard conforming compiler
+>may (at its discression) issue one or more disgnostics[...]
+
+I'd say you showed much more discretion in your invention of "disgnostics"
+than in "discression."  False spurious diagnostics should indeed be refered
+to as "disgnostics."  Lovely word!

I will work on my spelling.

+----------
+Ron Guilmette:
+>unsigned long overflow = LONG_MAX + 3; /* ERROR */
+
+Norman Diamond:
+>Again I see no violation of a constrant.
+
+Ron Guilmette:
+>The Technical Information Bulletin #1 (RFI #31) issued by x3j11 makes it
+>clear that it is x3j11's interpretation that this contains a constraint
+>violation (of the second constraint given in 3.4).
+
+Sigh.  But wait!  Do you have the RFI's on line?

No, but they should be available from x3j11.

+----------
+Ron Guilmette:
+>#5)  GCC incorrectly issues an error for the following standard-conformant
+>     code.  (Note that `wchar_t' is the same as type `long int' on i486-svr4
+>typedef long int wchar_t;
+>wchar_t array5[4] = L"abcd";
+
+[later]
+>Norman has incorrectly presumed that GCC's error in this case has something
+>to do with the definition of the type `wchar_t'.  In fact that is entirely
+>besides the point.  The above code is accepted by GCC 2.3.3 if the explicit
+>array size is changed from `4' to `5'.
+
+I still think the implementation is allowed to play dirty pool...

As I have previously noted, standard conformant implementations are allowed
(due to the abundant loosness in the ANSI C standard) to issue what I would
characterize as "too many" diagnostics... but they are not allowed to issue
too few.  A conformant implementation may issue a diagnostic because it
does not like the way your hair is parted.  It may not however fail to
issue a required diagnostic, regardless of how you part your hair.

Because implementations are permitted (by the standard) to issue diagnostics
for any arbitrary condition, or for any arbitrary input translation unit,
no "bug report" suggesting that a given implementation gave "too many"
errors for some given piece of code can be anything other than a comment about
the "quality of implementation" provided.  (And that it all I intended this
to be.)

While I am not happy that the framers of the ANSI C standard choose to
provide implementors with a legal way to (in effect) get away with murder,
I accept the standard as it is, and I acknowledge that any reports I may
have posted here (or which I may post in the future) which claim that
such-and-such a compiler is rude (because it issues "too many" errors) are
really only comments about the "quality" of the implementation in question.

+----------
+Regarding #6, we agreed that GCC failed, though we disagreed on the reason and
+on what results we think should be correct.  It would be nice if Mr. Guilmette
+had followed that thread, not just my wisecrack about the disgnostic.

Case #6 was indeed interesting.  Here it is again:

	extern volatile struct s evs;
	void evs_test () { evs; }

I'm glad that Norman agrees that GCC failed this case (a fact which always
seemed rather evident to me, especially since the compiler outright crashed).

In this example, an identifier which designates an object which has an
incomplete type is used within an expression.

Even after reading the first sentence in the "semantics" subsection of
section 3.3.1, and looking at the syntax rules given just above that, I
am not able to state with total certainty that this example either does or
does not violate the syntax rules given in 3.3.1.  It seems to me that
the whole issue (of the validity or invalidity of the above code) rests
upon one's interpretation of the first "semantics" sentence in 3.3.1.
It says:

	"An identifier is a primary expression provided it has been
	declared as designating an object (in which case it is an lvalue
	or a function (in which case it is a function designator)."

Does the identifier which forms the expression in the above code "designate
an object" even though its type is an incomplete type (rather that an
object type)?

I think the answer to that question is "yes", the identifier *does* designate
an object (which perhaps has a complete type in some other translation unit
of the program), but I still think that the above code it blatantly wrong
(from a strictly pragmatic standpoint) and I would have liked it if the
stabndard has indicated exactly that in a clear fashion.

I guess what I'm saying is that I think x3j11 messed up on this small point.
I think the standard should have said ""An identifier is a primary expression
provided it has been declared as designating an object *and* providing
the type of the identifier is an object type..."

Perhaps some current and/or former member of x3j11 would care to comment.

P.S.  Note that `volatile' has no well-defined meaning (as far as the
standard is concerned) so the presence or absence of the `volatile'
qualifier in the above example is not directly relevant to the validity
or invalidity of the code (which would be the same either with or without
the volatile qualifier in there).  I just put in the `volatile' qualifier
because that (apparently) is the one extra kicker needed to entice GCC
into crashing.

-- 

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra