Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!jit533!diamond From: diamond@jit533.swstokyo.dec.com (Norman Diamond) Newsgroups: comp.std.c Subject: Re: Can an implementation ``pre-qualify'' a standard type? Message-ID: <1991Jun11.034756.1944@tkou02.enet.dec.com> Date: 11 Jun 91 03:47:56 GMT References: <1991Jun10.232144.24618@twinsun.com> Sender: usenet@tkou02.enet.dec.com (USENET News System) Reply-To: diamond@jit533.enet@tkou02.enet.dec.com (Norman Diamond) Organization: Digital Equipment Corporation Japan , Tokyo Lines: 60 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 > 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 . 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 actually contains the text typedef volatile int sig_atomic_t; and then a programmer does #include 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 actually says volatile, only that it behaves as if volatile were there. Again, for #include volatile sig_atomic_t x; it can be low-quality and issue a spurious diagnostic, but it cannot reject the code. However, for #include 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 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.