Marc Recht <[EMAIL PROTECTED]> writes: > The standard is specified to get the standard functions. Eg. if i specify > _POSIX_C_SOURCE=200112L then I want (for example) POSIX's flockfile, if the > OS supports POSIX. This doesn't mean that I don't want rpc. This means that > I need to change third party code, which needs POSIX functions, not to > declare POSIX/POSIX_C_SOURCE/XSI to get BSD/other functions (and inderectly > the POSIX 200112 functions).
Again, I'll point you at section 2.2 of POSIX.1-2001: : 2.2.1 Strictly Conforming POSIX Application : : A Strictly Conforming POSIX Application is an application that : requires only the facilities described in IEEE Std 1003.1-2001. [...] 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. > Since it isn't that way on any UNIX (at least I know about) vendors are > forced to do special treatment for FreeBSD. Which is IMHO really bad and > may lead to less support for FreeBSD. 4.4BSD (and earlier?) and most derived systems have many conditionals to prevent namespace pollution in the standards-case. 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. > IMHO this is bad and breaks compilation of much third-party code. 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've read/looked at the standard (see my posting to standards@) and I don't > think it forces FreeBSD's behaviour. I even think FreeBSD's behaviour isn't > the spirit of the standard. FreeBSD's behaviour is consistent with BSD's behaviour. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
