__STDC__ and POSIX

[Mark H. Colburn]

In article <9436 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>The actual scheme adopted in the final IEEE Std 1003.1 wasn't
>quite what X3J11 had suggested; in fact it's sort of the converse.
>They permit an application (NOT the implementation) to define the
>macro _POSIX_SOURCE, which (a) makes available POSIX extensions
>and (b) removes unconstrained extensions that Std 1003.1 would
>otherwise have permitted in headers.  However, the intent appears
>to be that POSIX-mandated extensions be available in the headers
>even when _POSIX_SOURCE is NOT defined by the application, and
>that contradicts ANSI C.

It is possible, I think, to put together a header which conforms to
both standards.   For example:

---------------------------------------------------------------------------
#ifndef __LIMITS_H
#define __LIMITS_H

/* Defines */

#define CHAR_BIT	8		/* number of bits in a "char" */
#define CHAR_MAX	UCHAR_MAX	/* max value for "char" */
#define CHAR_MIN	0		/* min value for "char" */
#define INT_MAX		32767		/* max value for "int" */
#define INT_MIN		-32767		/* min value for "int" */
#define LONG_MAX	2147483647	/* max value for "long int" */
#define LONG_MIN	-2147483647	/* min value for "long int" */
#define MB_LEN_MAX	1		/* max bytes in a multibyte char */
#define SCHAR_MAX	127		/* max value for "signed char" */
#define SCHAR_MIN	-127		/* min value for "signed char" */
#define SHRT_MAX	32767		/* max value for "short int" */
#define SHRT_MIN	-32767		/* min value for "short int" */
#define UCHAR_MAX	255		/* max value for "unsigned char" */
#define UINT_MAX	65535		/* max value for "unsigned int" */
#define ULONG_MAX	4294967295	/* max value for "unsigned long" */
#define USHRT_MAX	65535		/* max value for "unsigned short" */

#ifdef _POSIX_SOURCE

#define MAX_INPUT	256	/* Max numbef of bytes in terminal input */
#define NGROUPS_MAX	1	/* Max number of suplemental group id's */
#define PASS_MAX	8	/* Max number of bytes in a password */
#define PID_MAX		30000	/* Max value for a process ID */
#define UID_MAX		32000	/* Max value for a user or group ID */
#define ARG_MAX		4096	/* Nax number of bytes passed to exec */
#define CHILD_MAX	6	/* Max number of simultaneous processes */
#define MAX_CANON	256	/* Max numbef of bytes in a cononical queue */
#define OPEN_MAX	16	/* Nax number of open files per process */
#define NAME_MAX	14	/* Max number of bytes in a file name */
#define PATH_MAX	255	/* Max number of bytes in pathname */
#define LINK_MAX	8	/* Max value of a file's link count */
#define PIPE_BUF	512	/* Max number of bytes for pipe reads */

#endif /* _POSIX_SOURCE */
#endif /* __LIMITS_H */
---------------------------------------------------------------------------

In the example above, the POSIX related defines will only be used if
_POSIX_SOURCE is defined.  Therefore, if it is not defined, there should be
no namespace pollution.

I would hope that ANSI is not attempting to say that the only materail that 
is allowed in an ANSI C conforming header is that material which is in the
ANSI C standard.  That would cause problems with virtually any kind of
optional extions.  I would (grudingly) agree that the namespace pollution
should not be visible unless a specific action is taken, such as defining
_POSIX_SOURCE.

I have always felt that the ANSI C position on namespace pollution was a
little parochial.  Obviously, it is causing problems with other ongoing,
and useful, standards such as IEEE 1003 (POSIX).

>I think the logical consequence of all this is that in a
>simultaneously ANSI C and IEEE 1003.1 conforming implementation,
>applications would have to be sure to defined _POSIX_SOURCE if
>they want to get at the POSIX-specific symbols in those headers
>specified by the C Standard.  This is obviously a nuisance, and
>consequently it is probable that there will be few attempts to
>provide simultaneously-conforming implementations and fewer
>attempts on the part of applications to use them.  This is a
>real lossage.

I must be confused here, because I do not understand how an application
can be both ANSI C conforming and P1003.1 conforming if it is attempting
to use features which only are available in 1003.1.  If the application
is using only those features available to ANSI C, then it would be able
to #undef _POSIX_SOURCE, or just ignore _POSIX_SOURCE.  I don't see how 
this would cause the problems with the development of applications which 
you mentioned.

You said earlier that the symbol _POSIX_SOURCE would be able to be 
predefined (for example by the pre-processor), so why should the 
application have to define it.  It should maybe test for it, if it going 
to optionally use 1003.1 facilities.

I think that an application which is being developed for strict ANSI C
environments on a P1003.1 conforming system should take additional steps, 
such as #undef _POSIX_SOURCE, simply to make sure that the available
extensions in 1003.1 are not used.

Another alternative, would be for P1003.1 conforming systems to provide a
flag for the compiler, such as -strict_ansi, which does not define
_POSIX_SOURCE.

>	The new default compilation environment predefines
>	_POSIX_SOURCE "on behalf of the application", i.e. it is
>	NOT considered as being provided by the official
>	"implementation" but by the "program" being compiled.

I would rather have the implementation provide it.  That way a program can
be portable, without user intervention.  I can have a program which has 
routines test for ANSI C conformance using __STDC__ and test for POSIX 
conformance, via the _POSIX_SOURCE test macro, and use the POSIX routines 
if they are available, othewise, use some other form of routine.

I already have applications which do this.  Admittedly, I must currently
define _POSIX_SOURCE by hand, since I do not have a strictly conforming
P1003.1 system yet.

>	Except for the header extensions enabled by _POSIX_SOURCE,
>	the ANSI C Standard is obeyed.

They could be obeyed simply by #undef _POSIX_SOURCE, couldn't it?

-- 
Mark H. Colburn                  "They didn't understand a different kind of 
NAPS International                smack was needed, than the back of a hand, 
mark at jhereg.mn.org                something else was always needed."