> For example, the symbol SEEK_SET is supposed to be defined in 'stdio.h'
> (according to the POSIX standard, that is), but it's usually in
> 'unistd.h' instead-- but not always.
must be #defined in stdio.h. This is not a POSIX requirement. The only
POSIX constraints on stdio.h are that it must #define L_ctermid and
STREAM_MAX and declare fdopen() and fileno() if _POSIX_SOURCE is #defined.
It may optionally #define L_cuserid if _POSIX_SOURCE is #defined.
POSIX 1003.1 _does_ however, require that unistd.h #define SEEK_SET &c if
_POSIX_SOURCE is #defined. Thus, if you desire POSIX conformance, #include
unistd.h.
Are you sure about the SunOS headers? Here's a test I ran on my SPARC atQuote:> Sometimes, it's not defined at all.
> GNU, for example, puts it in 'unistd.h'. The headers in SunOS 4.1.3 don't
> define it at all, and Centerline's products define it in 'stdio.h'.
work:
% fgrep SEEK_SET /usr/include/unistd.h
#ifndef SEEK_SET
#define SEEK_SET 0 /* Set file pointer to "offset" */
% uname -a
SunOS epimbe 4.1.1 1 sun4c
Perhaps they've moved unistd.h to /usr/5include since 4.1.1??
I do agree on this, and am rapidly tiring of system dependencies beingQuote:> As a result, the code ends up littered with an incomprehensible mess of
> #ifdef's and #defines, to hack around the peculiarities of each
> environment.
handled by #ifdefs.
I've found the "POSIX Programmer's Guide" (Donald Lewine, O'Reilly, ISBN
0-937175-73-0) to be priceless. I strongly recommend this book to anyone
using C, whether they be UNIX programmers or not (but particularly if they
are). It not only helps understand "what is defined where and by which
standard", but also helps programmers to "Do the Right Thing" by clarifying
what is POSIX conformant and what is historical baggage.
--
---------------------------------------------------------------------------
Jim Vlcek UNIX for $166!
uunet!molly!vlcek Novell UnixWare from Information Foundation