🚀 go-pugleaf

In article <C02I8I.58I@jrd.dec.com>, diamond@jit533.jit.dec.com (Norman Diamond) writes:
|> In article <1992Dec30.011211.11409@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
|> >-----------------------------------------------------------------------------
|> >#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.
|> 
|> I believe that diagnostics are allowed to contain spurious line numbers unless

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?

|> they follow a #line directive.  (And of course a #line directive is allowed to
|> command similar garbage.)
|> >-----------------------------------------------------------------------------
|> >#8)  GCC [-pedantic-errors] fails to issue errors for the following
|> >void test_0 (char);
|> >void test_0 (c) char c; { }
|> 
|> Again (as in #1) I see no violation of a constraint.

This is not the same as #1, and there is a constraint violation here:

Section 3.5 "All declarations in the SAME SCOPE [emphasis mine] that
refer to the same object or function shall specify compatible types."
These two declarations are in the same scope, whereas in #1, the scope
of the declaration ended before the definition.

|> >-----------------------------------------------------------------------------
|> >#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; }
|> 
|> Again I see no violation of a constraint.  Furthermore, if you returned

Me neither, but...

|> 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.

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?

|> >-----------------------------------------------------------------------------
|> >#10)  GCC [-pedantic-errors] fails to issue an error for the following invalid
|> >void (*func_ptr) ();
|> >int i;
|> >void test () { func_ptr = i ? 0 : 0; }         /* ERROR */
|> 
|> The code looks valid to me.  The conditional expression  i ? 0 : 0  is an
|> integral constant expression with value 0.  Null pointer constants can be
|> assigned to function pointers.  (I expect no debate on this one.)

I'd like to debate you on this one, if I may. :-). Section 3.4 says,
"An integral constant expression ... shall only have operands that are
integer constants [and other types of obviously constant stuff]". The "i"
used as the first operand of the conditional operator does not qualify, 
regardless of the fact that its value does not affect the value of the
expression as a whole.

|> >-----------------------------------------------------------------------------
|> >#11)  GCC fails to issue errors for the following invalid C code involving
|> >      comparison operators, even when the -pedantic-errors option is used.
|> [Much editing by N.D.]
|>  int b_array_src[3];
|>  extern int u_array_src[];
|> >int i;
|> >void test_relational_operators () {
|> >  i = & u_array_src > & b_array_src;            /* ERROR */
|> >}
|> >int u_array_src[20] = { 0 };    /* complete its type */
|> 
|> Hmm, we agree that GCC failed to conform this time, but I find the constraints
|> for this very odd.  I wonder why there wasn't one allowance for "both operands
|> are pointers to qualified or unqualified versions of compatible object or
|> incomplete types."  The semantics could handle it without further adjustment.

Yes, I wondered the same thing when I looked it up.

|> >-----------------------------------------------------------------------------
|> >#12)  GCC fails to issue errors for the following invalid C code involving
|> >      the binary `-' operator, even when the -pedantic-errors option is used.
|> [Declarations similar to #11.]
|> >  i = & u_array_src - & b_array_src;            /* ERROR */
|> 
|> A more serious problem.  Again, we agree that GCC failed to conform.

Why is this one more serious?

|> >-----------------------------------------------------------------------------
|> >#19)  GCC fails to issue an error for the following pair of incompatible
|> >      function declarations, even when the -pedantic-errors option is used.
|> >extern const int func_4 ();
|> >extern int func_4 ();                   /* ERROR */
|> 
|> For the fourth time, this does not violate a constraint.

Yes it does. Sections 3.5.3 and 3.5.4.3 indicate that the two declarations
are not compatible, and the constraint in 3.5 says that they must be
compatible if they are in the same scope.

|> >-----------------------------------------------------------------------------
|> >#20)  GCC incorrectly issues errors for the following standard-conformant
|> >      ANSI C code when the -pedantic-errors option is used.
|> >static enum E1 { red, green, blue};
|> >static struct S1 { int member; };
|> >static union U2 { int member; };
|> >void foobar () {
|> >	auto enum E2 { red, green, blue };
|> >	auto struct S2 { int member; };
|> >	auto union U2 { int member; };
|> >}
|> 
|> Spurious diagnostics are allowed, though now they return to the status of
|> unfriendly and misleading.  What happened when you tried executing it?

These diagnostics are prefectly friendly and very helpful. Since the
declarations allocate no storage (there's no object being defined), a 
storage class specifier is useless and superfluous.

|> --
|> 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?

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com