Path: utzoo!utgpu!attcan!uunet!mcvax!ukc!cam-cl!am
From: am@cl.cam.ac.uk (Alan Mycroft)
Newsgroups: comp.lang.c
Subject: Oddities in ANSI 3rd review
Message-ID: <253@gannet.cl.cam.ac.uk>
Date: 2 Aug 88 13:48:06 GMT
Sender: news@cl.cam.ac.uk
Reply-To: am@cl.cam.ac.uk (Alan Mycroft)
Organization: U of Cambridge Comp Lab, UK
Lines: 31

The following two points appear to be oddities in ANSI 3rd public review
spec.
1.  The function
        int f() { int x; char y; return sizeof(x)==sizeof(y); }
    seems required to return 1!!!!
    Reasoning: 3.2.1.1 says:
      "A char ... may be used in an expression wherever an int may be used ...
       the value is converted to an int."
    sizeof(.) is certainly a context in which an int may be used and
    so sizeof(<char variable>)==sizeof(int).
    Note that sizeof(char) probably differs from sizeof(<char variable>).
    I observe that the spec goes to some great trouble to specify
    where an array or function is converted to a pointer (3.2.2.1) whereas
    the notionally(?) identical contexts where char is converted to int
    suffers from sloppy drafting. (Convince me I'm wrong!)
2.  4.12.1:  "[In <time.h>] 'struct tm'  ... shall contain *at least*
     the following members... int tm_sec; ...".
    However, it would seem that an *implementation* would be non-conforming
    if it contained more members:  Suppose an implementer added a field
    'foo' (say) to struct tm.  Then the program
        #define foo @@@@@whizz!!!
        #include <time.h>
    would not compile (assuming <time.h> was textual).
    Hence the implementor can only add names in the reserved space of _A-Z or
    __A-Za-z0-9_.  This same remark obtains for views like:
>In <7351@cit-vax.Caltech.Edu> beckenba@cit-vax.UUCP (Joe Beckenbach) writes:
>>	Showing just the members seems to indicate to me that the members
>>listed are definitely there, but other members might be as well which
>>should really not be tampered with. This is simply information-hiding
>>which might be better done implemented in software than by lack of reference
>>in the documentation.