Re: sys/file.h and POSIX

2002-12-09 Thread Garrett Wollman
< said: > may != MUST. We do not pollute the name space. Providing additional > facilities pollutes the name space, breaking strictly conforming > programs. Not necessarily. The Standard reserves certain namespaces for the implementation's use. However, none of the examples people are complai

Re: sys/file.h and POSIX

2002-12-09 Thread Marc Recht
may != MUST. We do not pollute the name space. Providing additional facilities pollutes the name space, breaking strictly conforming programs. Hmm, I can't see why a __EXTENSIONS__ (like Solaris has) would break posix confirming programms. But, it would help for eg. autoconf third-party apps w

Re: sys/file.h and POSIX

2002-12-09 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]> Marc Recht <[EMAIL PROTECTED]> writes: : > 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

Re: sys/file.h and POSIX

2002-12-09 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]> Marc Recht <[EMAIL PROTECTED]> writes: : > Why are you specifying a standard and then using features outside its : > scope? Either you want a BSD environment (in which case don't specify : The standard is specified to get the standard functions. Eg. if i

Re: sys/file.h and POSIX

2002-12-08 Thread Marc Recht
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

Re: sys/file.h and POSIX

2002-12-08 Thread Mike Barcroft
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

Re: sys/file.h and POSIX

2002-12-08 Thread Marc Recht
Why are you specifying a standard and then using features outside its scope? Either you want a BSD environment (in which case don't specify 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 su

Re: sys/file.h and POSIX

2002-12-08 Thread Mike Barcroft
[CC'd port's maintainer.] Vasyl S. Smirnov <[EMAIL PROTECTED]> writes: > On Sun, Dec 08, 2002 at 01:17:15PM +0100, Marc Recht wrote: > > Hi! > > > > While compiling some third-party code I got this: > > gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600 > > -D_XOPEN_SOURCE_EXTENDED=1 test.c > >

Re: sys/file.h and POSIX

2002-12-08 Thread Mike Barcroft
Marc Recht <[EMAIL PROTECTED]> writes: > Hi! > > While compiling some third-party code I got this: > gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600 > -D_XOPEN_SOURCE_EXTENDED=1 test.c > In file included from test.c:2: > /usr/include/sys/file.h:130: syntax error before "u_int" > > This makes

Re: sys/file.h and POSIX

2002-12-08 Thread Vasyl S. Smirnov
On Sun, Dec 08, 2002 at 01:17:15PM +0100, Marc Recht wrote: > Hi! > > While compiling some third-party code I got this: > gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600 > -D_XOPEN_SOURCE_EXTENDED=1 test.c > In file included from test.c:2: > /usr/include/sys/file.h:130: syntax error before "u_