Path: utzoo!attcan!uunet!lll-winken!ames!ncar!tank!shamash!com50!jhereg!mark From: mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) Newsgroups: comp.std.c Subject: Re: __STDC__ and POSIX Message-ID: <399@jhereg.Jhereg.MN.ORG> Date: 19 Jan 89 22:48:25 GMT References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu> <9405@smoke.BRL.MIL> <860@auspex.UUCP> <866@auspex.UUCP> <9436@smoke.BRL.MIL> Reply-To: mark@jhereg.MN.ORG (Mark H. Colburn) Organization: Minnetech Consulting, Inc., St. Paul MN Lines: 128 In article <9436@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) 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@jhereg.mn.org something else was always needed."