🚀 go-pugleaf

An e-mail correspondant advised that GCC's -pedantic-errors option is virtually
(if not actually) documented as yielding a non-conforming implementation.
It turns all warnings into errors and causes compilation to be aborted, even
for spurious-but-friendly (and spurious-but-unfriendly) warnings.  If this is
true, Mr. Guilmette's first step should invoke a conforming implementation and
post the results before this goes much further.
----------
Ron Guilmette:
>#8)  GCC fails to issue errors for the following erroneous code, even when
>     the -pedantic-errors option is in effect.  [char shorter than int here]
>void test_0 (char);
>void test_0 (c) char c; { }

Norman Diamond:
>I see no violation of a constraint.

An e-mail correspondent pointed out the constraint in ANSI Classic section 3.5,
so GCC probably fails this test, and I failed it :-)

Ron Guilmette's #19 is in the same category as #8.
----------
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

Norman Diamond:
>I believe that diagnostics are allowed to contain spurious line numbers unless
>they follow a #line directive [...]

Chris Volpe:
>I believe the diagnostics are allowed to say anything they want, and need not
>even supply a line number. However, I don't understand the "unless they follow
>a #line directive" part. Where does this come from?

If the vendor volunteers an implementation definition saying that diagnostics
include line numbers, then a #line directive affects subsequent diagnostics.
ANSI Classic section 3.8.4, page 94 lines 10 to 11:  "causes the implementation
to behave as if the following sequence of source lines begins with a source
line that has a line number as specified by the digit sequence".  In fact if
the vendor volunteers such an implementation definition, then preceding
diagnostics are also bound by lines 5 to 7 of the same section.  However, if
the current token was not read during translation phase 1 (e.g. was created
using the ## operator) then the standard is unhelpful.  And if the current
token was read during translation phase 1 as part of a macro replacement
string, then I'll bet every implementation in the world will get this wrong.
Good thing that vendors don't have to volunteer non-spurious line numbers :-)
----------
Ron Guilmette:
>#9)  GCC fails to issue errors in cases where a static function is referenced
>     but never defined, even when the -pedantic-errors option is used.
>static void s (); int main () { s (); return 1; }

Norman Diamond:
>Again I see no violation of a constraint.  Furthermore, if you returned
>EXIT_SUCCESS instead of 1, I believe it would be strictly conforming.
>Hard to believe, isn't it?  My best guess is that the invocation of s()
>acts as a no-op.  The standard doesn't seem to permit any other behavior.

Chris Volpe:
>Yeah, very hard to believe. Are you saying that all undefined functions must
>behave as no-ops? Or is there something special about undefined static
>functions?

I thought the standard failed to require definitions for static functions, but
Ron Guilmette later pointed out that the second Constraints paragraph in ANSI
Classic section 3.7 covers this.  I missed it while finding the Semantics
paragraph that covered externals.  GCC probably fails and I failed.
----------
Ron Guilmette:
>#10)  GCC [-pedantic-errors] fails to issue an error for the following
>void test () { func_ptr = i ? 0 : 0; }         /* ERROR */

Norman Diamond:
>The code looks valid to me.  The conditional expression  i ? 0 : 0  is an
>integral constant expression with value 0.

Whoops, it's an integral non-constant expression that happens to have value 0.
The implementation is only allowed to evaluate one of those 0's, and doesn't
know which one until run-time.  GCC probably fails and I failed.
----------
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!
----------
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?  If so, please e-mail them
to me!  (Someone else who has them on-line ignored my request, sigh....
I still have a subset of them, on two unreadable backup tapes, sighhhhhhhhh.)
----------
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, including
being dirty enough to ACCEPT some of your efforts at random.  However, I think
it's clear that you could construct another example which GCC would reject
without excuse, and yes it seems clear now where GCC's failure is.
----------
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.
--
Norman Diamond                diamond@jit.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Pardon me?  Or do I have to commit a crime first?