std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/20/88)
From: uunet!brl-smoke.ARPA!gwyn (Doug Gwyn ) In article <1086@bentley.UUCP> cox@bentley.UUCP (59463-MH Cox) writes: >The proposed ANSI standard C has produced >a lot of new data types: size_t, time_t, etc. I was starting to >adopt their "_t" convention for my own data types, when >I suddenly realized (excuse me, if this is obvious to everyone >else :-) I might be headed for a type clash with a future >ANSI C typedef. Did the ANSI C committe intend to reserve all >typedefs of the form *_t for their own use? Should I >avoid typedefs of this form in my applications? The following is my own opinion and should not be taken as an official X3J11 response: Only those portions of the name space explicitly identified in the ANSI C standard as reserved for implementation use are unsafe for portable applications to use. *_t (where * starts with a alphabetic character) is not reserved except for the specific types such as time_t named in the standard. However, you may have a problem if you define your own *_t types in a POSIX environment, since POSIX introduces some more types. What IEEE Std 1003.1 should say, but as of Draft 12 as modified so far during the balloting process does not say, is that inclusion of <sys/types.h> may define additional types (other than those explicitly named in the POSIX standard) with names of the form *_t. What the revised draft currently says is that <sys/types.h> may define additional types having any names whatsoever; this is clearly not in line with the professed goal of "promoting portable applications". A similar botch is found in IEEE Std 1003.1 <signal.h>, which should only allow (besides more SIG* names) additional macros having names of the form SA_*, but currently also allows any names whatsoever to be usurped by the implementation. These problems with 1003.1 are in addition to the generic one of a contradiction between the requirements of ANSI C and of POSIX for what names the headers that they share can define. The X3J11 committee sent 1003.1 a letter explaining the problem and suggesting a simple solution (that in practice would usually be met by the application programmer arranging for <unistd.h> to be included before the headers in question). However, so far 1003.1 has come up with a different "solution" that merely avoids solving the problem. My guess is that they don't understand the issue; or possibly they have yielded to pressure to bless the existing messy situation in the UNIX world as "already POSIX conformant", in which case one wonders what the point of the standard is. (If you say that it is becoming mostly a marketing ploy rather than an aid to programmers, I might not disagree.) Since it appears that 75% of the balloters have now voted yea on draft 1003.1, we are in danger of getting a standard that does not solve these fundamental portability problems. I have been urging procurement specifications that require more than 1003.1 conformance, for example ANSI C and SVID compliance, with an order of precedence specified for cases where the several specifications conflict (with ANSI C first, since it is more basic and universal than the other specs). This seems to be the only safe course given the weaknesses and incompleteness of 1003.1 as it now stands. (It has gotten better than it was a year ago, though, mostly under NBS influence.) Volume-Number: Volume 13, Number 27
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (03/24/88)
Doug Gwyn writes: >Since it appears that 75% of the balloters have now voted yea >on draft 1003.1, we are in danger of getting a standard that >does not solve these fundamental portability problems. Just to clarify somewhat the rather confusing IEEE balloting procedure currently going on for 1003.1: 1003.1 is not a standard yet. 75% of the balloting quorum returned ballots during the initial thirty day period, and 75% of those were positive, allowing a ballot resolution period, which was set at ten days. There are claims that 77% positive ballots were received during that resolution period. But the period was too short for many people to respond, and there were other problems (all three of Institutional Representatives, from USENIX, /usr/group, and X/OPEN, as well as others, sent letters to the IEEE Standards Board pointing this out). There will be another resolution period, probably in April. At this point if you haven't already balloted, you can't. But there's still some time for improvements in 1003.1, and some problems may have been resolved at the 1003 meeting last week in D.C. The IEEE Standards Review Committee accepted 1003.1 as a conditional standard at their last meeting, a week or so ago. I don't know what that means, but I do know it does not mean that 1003.1 is a standard yet. Volume-Number: Volume 13, Number 28