🚀 go-pugleaf

In article <1993Jan1.114912.22617@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>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 impleme

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

Neither of these asserts that a conforming implementation is invoked.
If they invoke a non-conforming implementation, they can still reject
programs on the basis of the implementor's personal aesthetics.
This question still needs clarification.

>I will work on my spelling.

No problem.  I still think that "disgnostics" is a lovely word, and accurately
describes false misleading spurious diagnostics :-)

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

>>>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...
[Even though I no longer think this will excuse other possible trial cases.]

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

We agree, but this is not the problem here.  You complained that it DID
issue a diagnostic, one which is NOT required, and we were only wondering
whether it was allowed to cause rejection.

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

We agree, and this is almost the problem.  However, I'm pretty sure that a
similar trial program (where you #include one of the relevant standard headers
instead of typedef'ing wchar_t yourself) will probably yield a rejection which
is more than just "quality of implementation."  That will be worth reporting.

>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. [...] 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.
>	"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 you've found a bug in the standard.  An identifier with incomplete
type is sometimes considered to designate an object and sometimes considered
not to designate an object.  I think it is intended for programmers to be
able to apply unary & to take the address of an incomplete-typed something,
so the answer to your question seems to be "yes" for 3.3.1.

Regardless, the implementation-defined access to evs must be one that neither
evaluates nor modifies evs, due to the definitions of what an expression does
(the semantics of other sections on expressions).  This expression contains
no operator that evaluates and no operator that modifies.  Therefore the size
of the object does not have to be known, and the expression is valid.

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

I'd rather see the current COMMITTEE of x3j11 comment via RFI.
--
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?