Date: Sun, 08 Dec 2002 18:31:36 +0100 From: Marc Recht <marc@informatik.uni-bremen.de> To: Mike Barcroft <mike@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: sys/file.h and POSIX Message-ID: <659000000.1039368696@leeloo.intern.geht.de> In-Reply-To: <20021208114718.G74206@espresso.q9media.com> References: <509390000.1039349835@leeloo.intern.geht.de> <20021208104335.E74206@espresso.q9media.com> <619340000.1039364545@leeloo.intern.geht.de> <20021208114718.G74206@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > A conforming application cannot make use of facilities outside the > scope of the standard. This means that if you define > _POSIX_C_SOURCE=200112L you don't want RPC. I don't said that the application is _strictly_ POSIX conforming. It only wants to use POSIX functions and RPC. FreeBSD's way seems to be not to define POSIX/XSI (and so) on to _indirectly_ get it and the BSD stuff > 4.4BSD (and earlier?) and most derived systems have many conditionals > to prevent namespace pollution in the standards-case. But more in a kind of aggregation like I want "this and that" (POSIX and stuff..). > So why do we do this? To prevent screwage of perfectly valid > applications that use the same keywords as system extentions to the > standard. For instance, the major() macro in <sys/types.h> is a very > common and likely to be used word, so it is not defined in the > standards case to prevent POSIX applications that define a different > major() macro from failing to compile. Hmm. The questions what makes more problems.. Maybe a solution could be to make a supported way to change the __BSD_VISIBLE from the "outside". Another idea would be to make a WANT_STRICT_POSIX. > Not really. Conforming applications have no trouble (obviously), > pseudo-conforming applications only need a little work (removing bogus > POSIX keywords that specify conformance), and non-conforming BSD > applications (the majority of software) have no problems. I had this in mind. http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html: A conforming implementation shall meet all of the following criteria: [...] 4. The system may provide additional utilities, functions, or facilities not required by IEEE Std 1003.1-2001. Non-standard extensions of the utilities, functions, or facilities specified in IEEE Std 1003.1-2001 should be identified as such in the system documentation. Non-standard extensions, when used, may change the behavior of utilities, functions, or facilities defined by IEEE Std 1003.1-2001. The conformance document shall define an environment in which an application can be run with the behavior specified by IEEE Std 1003.1-2001. In no case shall such an environment require modification of a Strictly Conforming POSIX Application (see Strictly Conforming POSIX Application ). So, defining POSIX should guarantee that a strictly POSIX conforming runs/compiles correctly. But not that a non-strictly POSIX conforming application won't. > FreeBSD's behaviour is consistent with BSD's behaviour. No. Eg. the rpc example works out-of-the-box on NetBSD 1.6. And only a _very_ small part of the UNIX world is BSD. Regards, Marc "Premature optimization is the root of all evil." -- Donald E. Knuth [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE984H47YQCetAaG3MRAmyiAJ9wjPBQDdiMRlkzoQBFQUMM8oDiyQCbBJbh DwbKcPnSyCSN5gRoOYzbxf8= =J/y3 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?659000000.1039368696>