NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/c/3288

Internet Message Format | 1992-12-30 | 5.7 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!crdgw1!rdsunx.crd.ge.com!bart!volpe
From: [e-mail] (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Standard conformance and GCC 2.3.3
Message-ID: <[e-mail]>
Date: 30 Dec 92 14:57:41 GMT
References: <[e-mail]>
Sender: volpe@bart (Christopher R Volpe)
Reply-To: [e-mail]
Organization: GE Corporate Research & Development
Lines: 138
Nntp-Posting-Host: bart.crd.ge.com

In article <[e-mail]>, [e-mail] (Ronald F. Guilmette) writes:
|> Most (but not all) of these twenty bugs are problems with standard conformance.
|> GCC is either issuing errors for valid ANSI C code or else it is failing to
|> issue errors for constructs which violate some constraint given in the ANSI
|> C standard.

It would be nice if the constraint in question were indicated. I would
like some justification for calling these constraint violations.

|>
|> -----------------------------------------------------------------------------
|> #1)  GCC fails to detect the error in the following code, even when the
|>      -pedantic-errors option is used.
|>
|> void foo ()
|> {
|>   extern void bar (int i, ...);
|>
|>   bar (99, 88, 77);
|> }
|>
|> void bar (int i, int j, int k) { }      /* ERROR */

What's the constraint violation?  The declaration with the ellipsis is out
of scope at the time the definition is seen, so the constraint in 3.5
about compatible types does not apply. The result is undefined behavior, not
a constraint violation.

|> -----------------------------------------------------------------------------
|> #2)  GCC fails to detect the error in the following code, even when the
|>      -pedantic-errors option is used.
|>
|> unsigned long overflow = LONG_MAX + 3; /* ERROR */

Again, which constraint is violated? The section on initialization says
nothing about overflow, so normal assignment rules apply. And in normal
assignment, overflow results in undefined behavior.

|> -----------------------------------------------------------------------------
|> #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.
|>
|>      Example:
|>
|> static void s (); int main () { s (); return 1; }

Is this a new bug? I get the expected diagnostic from gcc 2.2.

|> -----------------------------------------------------------------------------
|> #14)  GCC fails to issue errors for the following invalid C code involving
|>       invalid pointer type conversions, even when the -pedantic-errors option
|>       is used.
|>
|> struct incomp1; /* never completed */
|> struct incomp2; /* completed towards the end - may make a difference */
|>
|> typedef int             *p_to_object_type;
|> typedef struct incomp1  *p_to_incomp1_type;
|> typedef struct incomp2  *p_to_incomp2_type;
|> typedef int             (*p_to_func_type) ();
|>
|> p_to_object_type        p_to_object_value;
|> p_to_incomp1_type       p_to_incomp1_value;
|> p_to_incomp2_type       p_to_incomp2_value;
|> p_to_func_type          p_to_func_value;
|>
|> void
|> test ()
|> {
|>   p_to_func_value = (p_to_func_type) p_to_object_value;         /* ERROR */
|>   p_to_func_value = (p_to_func_type) p_to_incomp1_value;        /* ERROR */
|>   p_to_func_value = (p_to_func_type) p_to_incomp2_value;        /* ERROR */
|> }
|>
|> struct incomp2 { int i; };

What constraint is violated? The assignment proper stores a function
pointer value in a function pointer object in each case, so the types are
compatible there. The only questionable thing is the cast. The cast is
definitely illegal because it is not permitted in the "Semantics" section of
3.3.4, but the constraints section of 3.3.4 requires only that the operand have
scalar type and that the cast specify scalar type. That constraint is not
violated.

|> -----------------------------------------------------------------------------
|> #15)  GCC fails to issue errors for the following invalid C code involving
|>       invalid pointer type conversions, even when the -pedantic-errors option
|>       is used.
|>
|> struct incomp1; /* never completed */
|> struct incomp2; /* completed towards the end - may make a difference */
|>
|> typedef int             *p_to_object_type;
|> typedef struct incomp1  *p_to_incomp1_type;
|> typedef struct incomp2  *p_to_incomp2_type;
|> typedef int             (*p_to_func_type) ();
|>
|> p_to_object_type        p_to_object_value;
|> p_to_incomp1_type       p_to_incomp1_value;
|> p_to_incomp2_type       p_to_incomp2_value;
|> p_to_func_type          p_to_func_value;
|>
|> void
|> test ()
|> {
|>   p_to_object_value = (p_to_object_type) p_to_func_value;       /* ERROR */
|>   p_to_incomp1_value = (p_to_incomp1_type) p_to_func_value;     /* ERROR */
|>   p_to_incomp2_value = (p_to_incomp2_type) p_to_func_value;     /* ERROR */
|> }
|>
|> struct incomp2 { int i; };
|> -----------------------------------------------------------------------------

See my previous comments. Same thing applies here.

|> -----------------------------------------------------------------------------
|> #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; };
|> }

In my version (2.2), I get warnings, not errors. The warnings it gives are
perfectly reasonable.

--
==================
Chris Volpe
G.E. Corporate R&D
[e-mail]