eggert@twinsun.com (Paul Eggert) (06/11/91)
Can a conforming Standard C implementation header ``pre-qualify'' a
standard type by ``hardwiring'' a qualifier into its typedef? E.g. can
<signal.h> behave as if
typedef volatile int sig_atomic_t;
defines sig_atomic_t? Rumor has it that at least one would-be
conforming implementation does this to head off common programming errors.
If you answered ``yes'' to the above question, where does this sort of
thing stop, and why? Is `volatile' permitted but `const' forbidden here?
For example, can <stdio.h> behave as if
typedef const struct {/*...etc...*/} FILE;
defines FILE? Can <time.h> behave as if
struct tm { const int inconvenient; int tm_sec; /*...etc...*/};
defines struct tm? Can <stddef.h> behave as if
typedef const unsigned size_t;
defines size_t?diamond@jit533.swstokyo.dec.com (Norman Diamond) (06/11/91)
In article <1991Jun10.232144.24618@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: >Can a conforming Standard C implementation header ``pre-qualify'' a >standard type by ``hardwiring'' a qualifier into its typedef? E.g. can ><signal.h> behave as if > typedef volatile int sig_atomic_t; >defines sig_atomic_t? Rumor has it that at least one would-be >conforming implementation does this to head off common programming errors. The question is a bit ambiguous -- sometimes the implementation can "behave as if" that were done, but sometimes it cannot. I think only a masochistic implementor would actually put "volatile" there in <signal.h>. It is in a "constraints" section that a type qualifier may not appear more than once for the same object, including indirect appearances via typedef. So if a programmer were to say either volatile volatile int x; or typedef volatile int t; volatile t x; the implementation would be required to issue at least one diagnostic, and can arbitrarily choose whether to do the right thing or not. If <signal.h> actually contains the text typedef volatile int sig_atomic_t; and then a programmer does #include <signal.h> volatile sig_atomic_t x; then the programmer's code is legal. The implementation is allowed to be low-quality and issue spurious diagnostics, but it must do the right thing with this code. Now, you didn't say if <signal.h> actually says volatile, only that it behaves as if volatile were there. Again, for #include <signal.h> volatile sig_atomic_t x; it can be low-quality and issue a spurious diagnostic, but it cannot reject the code. However, for #include <signal.h> sig_atomic_t y; it can be high, low, or undecidable quality, behave as if y were declared volatile, and do the right thing. It is not entirely clear if this would be an advantage or not. An implementation can always make all objects behave in a volatile manner, and the second half of the preceding paragraph would be a special case. There's a slight difference between this and behaving as if the source code contains the word "volatile," because of the rules on syntax and "constraints" sections. >Can <stddef.h> behave as if > typedef const unsigned size_t; >defines size_t? No. A strictly conformant program is allowed to assign values to objects of type size_t, and a conformant implementation must obey it. Again, it could issue a spurious diagnostic, but it still must obey. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Permission is granted to feel this signature, but not to look at it.
gwyn@smoke.brl.mil (Doug Gwyn) (06/11/91)
In article <1991Jun10.232144.24618@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: > typedef volatile int sig_atomic_t; >... Rumor has it that at least one would-be >conforming implementation does this to head off common programming errors. That would not be a conforming implementation: (1) sig_atomic_t is required to be an "integral type", which is a technical term defined only as an unqualified type. (2) "volatile sig_atomic_t" is explicitly required to be supported, and if the typedef includes volatile qualification then the usage would violate a constraint in section 3.5.3 (X3.159-1989).