Safe to use *_t typedefs?

[Moderator, John S. Quarterman]

From: uunet!brl-smoke.ARPA!gwyn (Doug Gwyn )

In article <1086 at bentley.UUCP> cox at 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