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
--==========2616817794========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > A conforming application cannot make use of facilities outside the > scope of the standard. This means that if you define > _POSIX_C_SOURCE=3D200112L you don't want RPC. I don't said that the application is _strictly_ POSIX conforming. It only=20 wants to use POSIX functions and RPC. FreeBSD's way seems to be not to define POSIX/XSI (and so) on to=20 _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=20 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=20 make a supported way to change the __BSD_VISIBLE from the "outside".=20 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=20 not required by IEEE Std 1003.1-2001. Non-standard extensions of the=20 utilities, functions, or facilities specified in IEEE Std 1003.1-2001=20 should be identified as such in the system documentation. Non-standard=20 extensions, when used, may change the behavior of utilities, functions, or=20 facilities defined by IEEE Std 1003.1-2001. The conformance document shall=20 define an environment in which an application can be run with the behavior=20 specified by IEEE Std 1003.1-2001. In no case shall such an environment=20 require modification of a Strictly Conforming POSIX Application (see=20 Strictly Conforming POSIX Application ). So, defining POSIX should guarantee that a strictly POSIX conforming=20 runs/compiles correctly. But not that a non-strictly POSIX conforming=20 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=20 _very_ small part of the UNIX world is BSD. Regards, Marc "Premature optimization is the root of all evil." -- Donald E. Knuth --==========2616817794========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE984H47YQCetAaG3MRAmyiAJ9wjPBQDdiMRlkzoQBFQUMM8oDiyQCbBJbh DwbKcPnSyCSN5gRoOYzbxf8= =J/y3 -----END PGP SIGNATURE----- --==========2616817794==========-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?659000000.1039368696>