Date: Wed, 8 Jan 1997 22:20:50 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, dufault@hda.com Cc: hackers@freebsd.org Subject: Re: #include file xref philosophy Message-ID: <199701081120.WAA32757@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >Is there any reason for not following the posix line and having >> >include files resolve all their own dependencies? I'm talking about >> >> That's not the ANSI C line. POSIX.1 requires <sys/types.h> to be >> included before including any other POSIX header. > >How about "POSIX.1 sometimes requires that <sys/types.h> >be included before including some POSIX headers". They sprinkle >size_t all over the place so that old programs don't break. I'm only familiar with POSIX.1-1990. size_t is required to be declared by many ANSI C headers and this must be done (at least in the pure ANSI C case) without including <sys/types.h> (which doesn't exist in ANSI C). >Annex C has a summary of what types are defined in each header: > >mqueue.h mqd_t >semaphore.h sem_t These headers aren't in POSIX.1-1990 (or FreeBSD). >signal.h sig_atomic_t sigset_t siginfo_t sig_atomic_t is in ANSI C, sigset_t is in POSIX.1-1990, and siginfo_t is new (and not in FreeBSD). >stddef.h ptrdiff_t size_t wchar_t >stdio.h fpos_t size_t FILE >stdlib.h div_t ldiv_t size_t wchar_t >string.h size_t >times.h clock_t Same as in ANSI C. >sys/types.h dev_t ino_t nlink_t pid_t ssize_t gid_t mode_t off_t size_t uid_t >termios.h cc_t speed_t tcflag_t Same as in POSIX.1-1990. >time.h clockid_t size_t time_t clock_t timer_t size_t, time_t and clock_t are in ANSI C. clockid_t and timer_t are new (and not in FreeBSD). >So size_t is defined by stddef.h, stdio.h, stdlib.h, string.h, sys/types.h, >and time.h while off_t is only in sys/types.h. Same as in ANSI C and POSIX.1-1990. >(This is P1003.1b-1993) POSIX.1 reserves all names ending in _t if any POSIX.1 header is included. Thus an implementation may include <sys/types.h> if <sys/types.h> doesn't have any namespace pollution. However, an application that depends on this is unportable. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701081120.WAA32757>