Re: Define _POSIX_SOURCE in cygwin's features.h?
On Fri, Jan 13, 2006 at 07:47:48AM -0700, Eric Blake wrote: P.S. I know that Cygwin isn't fully compliant with POSIX specifications. One other thing to be aware of. If cygwin does define _POSIX2_VERSION in its headers, programs will assume that all features specified by POSIX are available. Coreutils, in particular, makes a compile-time decision about the default behavior of some of its apps, based on the value of _POSIX2_VERSION (of course, this decision is overridable at runtime by redefining _POSIX2_VERSION in the environment). An example of this would be that right now on cygwin, with coreutils 5.93, tail +4 defaults to the 1992 POSIX semantics of tail -n +4, because _POSIX2_VERSION was not detected at configure time. But if you start adding _POSIX* macros to features.h, to be more like Linux, and choose to move to the 2001 version of POSIX, then a recompilation of tail +4 would default to the semantics of tail ./+4. I was just reviewing this thread to begin thinking about preparing a plan of attack for this problem and I see that I forgot to thank you for this insight. This is exactly the kind of feedback I was hoping for. While I suspect that turning on _POSIX_SOURCE in cygwin's feature.h and cleaning up the fallout from that action in the header files may make some programs easier to port, I was wondering what the other side-effects would be. So, it sounds like the effect would be to make some applications behave more like linux, which is theoretically a good thing. But, since it will be a change in visible behavior, we may see some complaints. Actually, strike the may and substitute will. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 1/12/2006 10:31 AM: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. Any opinions on this? Eric? Well, since you asked me (what, am I now the POSIX guru?), POSIX has this to say about it: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html It is the responsibility of a POSIX-conformant app to define _POSIX_SOURCE to 1 if they want compliance with the 1992 version of POSIX.1, or to define _POSIX_C_SOURCE to 200112L if they want compliance with the 2001 version of POSIX. The definition must occur in the application's file before the inclusion of any standard header. By defining _POSIX*SOURCE, the application is specifically requesting that all namespace variables required or reserved by POSIX are visible, and no functions not required by POSIX and not in a reserved namespace are hidden, unless additional feature macros were also defined. (For example, defining _XOPEN_SOURCE to 600 is an additional feature macro to pull in the X headers.) In fact, POSIX states that defining only _XOPEN_SOURCE=600 is good enough that the system headers should then turn on _POSIX_C_SOURCE=200112L. Now what does this all mean to cygwin? Most apps don't care about strict compliance - they are more than willing to use extensions if it makes it easier to get the job done, so most apps don't define _POSIX_SOURCE or _POSIX_C_SOURCE before including headers. I agree with Samuel's conclusion - we can use the Linux trick of having a default configuration of gcc that turns on _GNU_SOURCE (itself a feature test, that turns on all other extensions), provided that gcc can also be told to be strictly compliant to a given standard (gcc's -ansi flag, among others). Then, when _GNU_SOURCE is defined, cygwin can also define _POSIX_SOURCE under the hood to allow developers to be lazy and not explicitly define it themselves when they don't care about strict compliance. In other words, the goal should be that unless the user EXPLICITLY asked for a certain namespace, by defining _POSIX_C_SOURCE themselves, we might as well be generous and give them everything. P.S. I know that Cygwin isn't fully compliant with POSIX specifications. One other thing to be aware of. If cygwin does define _POSIX2_VERSION in its headers, programs will assume that all features specified by POSIX are available. Coreutils, in particular, makes a compile-time decision about the default behavior of some of its apps, based on the value of _POSIX2_VERSION (of course, this decision is overridable at runtime by redefining _POSIX2_VERSION in the environment). An example of this would be that right now on cygwin, with coreutils 5.93, tail +4 defaults to the 1992 POSIX semantics of tail -n +4, because _POSIX2_VERSION was not detected at configure time. But if you start adding _POSIX* macros to features.h, to be more like Linux, and choose to move to the 2001 version of POSIX, then a recompilation of tail +4 would default to the semantics of tail ./+4. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDx72U84KuGfSFAYARAhzrAKCXvG9T8qf/jC72EiOfkV47h+Kr4wCdHXaQ d72MLCP3eLQR4qIgITkiYn4= =YNn9 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 1/12/2006 12:24 PM: This particular application was ircd. It was testing _POSIX_SOURCE (and a few other defines) to determine whether it should use setsid or a two-argument version of setpgrp, e.g.: #ifdef _POSIX_SOURCE setsid (); #else setpgr(..., ...); #endif That is a bug in ircd. It is ircd's responsibility to define _POSIX_SOURCE itself if it wants strict POSIX compliance. In other words, if ircd wants to guarantee that it will compile on all POSIX-compliant systems, it should have defined _POSIX_SOURCE and then it could blindly use setsid() without any further heartburn. But it is possible to be portable to more systems than just those that are POSIX-compliant, so the better approach for ircd would have been to do an autoconf test for the existance of setsid, whether or not _POSIX_SOURCE was defined, and not a test for the existance of _POSIX_SOURCE. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDx78U84KuGfSFAYARAqHtAKCPOxmuUCb1bWzkrNcHpUs7tJrNtACgrL9V X1SSS7bGJHZhfKSNkz8+SSA= =dXZ3 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Fri, Jan 13, 2006 at 07:47:48AM -0700, Eric Blake wrote: Now what does this all mean to cygwin? Most apps don't care about strict compliance - they are more than willing to use extensions if it makes it easier to get the job done, so most apps don't define _POSIX_SOURCE or _POSIX_C_SOURCE before including headers. I agree with Samuel's conclusion - we can use the Linux trick of having a default configuration of gcc that turns on _GNU_SOURCE (itself a feature test, that turns on all other extensions), provided that gcc can also be told to be strictly compliant to a given standard (gcc's -ansi flag, among others). Thank you for your feedback. I was just going to silently digest this but I can't let this particular one slide. I don't see how you credit *Samuel* with any conclusions other than the one that anyone who used _POSIX_SOURCE in source code was stupid and that I needed to read a book on posix. After making those observations for a couple of paragraphs he quoted a snippet of a header file that *I* included and said Well, that's ok then. I'm glad to have his permission on this, though. So, let me state a few things: 0) It is cygwin's goal to emulate linux (as per the cygwin web page). 1) linux defines _POSIX_SOURCE by default unless specific gcc command line options are specified (as per the code snippet that I posted). 2) I want cygwin to be *more* like linux (as per my repeated assertions in this thread and elsewhere). 3) The fact that the cygwin header files are currently inconsistent, and probably wrong, wrt _POSIX_SOURCE does not preclude fixing them to make them more like linux. Conclusion: newlib's headers are not close enough to glibc headers and that is what is causing people problems. Task for 1.5.20: Make cygwin's header files more like the linux header files. I'm sorry that my goals here were not clearer from my original message. I don't need anymore feedback about this. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. Any opinions on this? Eric? cgf P.S. I know that Cygwin isn't fully compliant with POSIX specifications. As far as I can tell by googling, _POSIX_SOURCE, despite the leading underscore, is in fact a user-land feature test macro that it is up to each individual application to decide whether to switch it on or not according to whether the application itself is compliant or not. IOW, the system headers should have nothing to say about it at all, although they may well want to react to it if it is defined at the time they are #included. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 05:40:35PM -, Dave Korn wrote: Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. Any opinions on this? Eric? P.S. I know that Cygwin isn't fully compliant with POSIX specifications. As far as I can tell by googling, _POSIX_SOURCE, despite the leading underscore, is in fact a user-land feature test macro that it is up to each individual application to decide whether to switch it on or not according to whether the application itself is compliant or not. No need to use google. Just grep for it in /usr/include on linux. _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE # undef _ISOC99_SOURCE # define _ISOC99_SOURCE 1 # undef _POSIX_SOURCE # define _POSIX_SOURCE 1 # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE199506L # undef _XOPEN_SOURCE # define _XOPEN_SOURCE 600 # undef _XOPEN_SOURCE_EXTENDED # define _XOPEN_SOURCE_EXTENDED 1 # undef _LARGEFILE64_SOURCE # define _LARGEFILE64_SOURCE1 # undef _BSD_SOURCE # define _BSD_SOURCE1 # undef _SVID_SOURCE # define _SVID_SOURCE 1 #endif So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
Hi, Christopher Faylor, le Thu 12 Jan 2006 12:59:08 -0500, a écrit : Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. If the package doesn't define _POSIX_SOURCE itself then it needs be fixed, not cygwin. _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. Indeed. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE ... # define _POSIX_SOURCE 1 ... #endif So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. No. It can create a lot of other problems. Maybe cygwin could #define _POSIX_SOURCE to 1 if the user _already_ defined _GNU_SOURCE. But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. Regards, Samuel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. I think it would be the opposite. 1) In glibc, _POSIX_SOURCE is defined by features.h based on a number of conditions[1]. The newlib/Cygwin features.h isn't nearly so thorough. [1] http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/include/features.h?cvsroot=glibc 2) After running a grep of /usr/include, it looks like arbitrarily defining _POSIX_SOURCE in Cygwin would cause a significant number of constants and functions to never be defined (and AFAICS there would be no simple way to undef it within code), without actually adding anything, for example: /usr/include/dirent.h:#if !defined(MAXNAMLEN) !defined(_POSIX_SOURCE) /usr/include/fnmatch.h:#ifndef _POSIX_SOURCE /usr/include/glob.h:#ifndef _POSIX_SOURCE /usr/include/grp.h:#if !defined(_POSIX_SOURCE) !defined(_XOPEN_SOURCE) /usr/include/grp.h:#ifndef _POSIX_SOURCE /usr/include/pwd.h:#ifndef _POSIX_SOURCE /usr/include/pwd.h:#ifndef _POSIX_SOURCE /usr/include/sys/dirent.h:#ifndef _POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/select.h:#if !defined (_POSIX_SOURCE) !defined (__INSIDE_CYGWIN_NET__) /usr/include/sys/stat.h:#ifndef _POSIX_SOURCE /usr/include/sys/types.h:# ifndef _POSIX_SOURCE /usr/include/sys/types.h:# if !(defined (_POSIX_SOURCE) || defined (_WINSOCK_H) || defined (__USE_W32_SOCKETS)) /usr/include/sys/unistd.h:#ifndef_POSIX_SOURCE 3) I think that, in many cases, _POSIX_SOURCE is defined in code if desired (and that would have been the best solution in the aforementioned case). 4) I'm sure I remember a few times that, even when _POSIX_SOURCE was defined in code, I had to #ifndef __CYGWIN__ that define due to compile errors; I can't remember having to manually add such a define, however. My $0.02, YMMV. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxpt3piWmPGlmQSMRAp2sAJ0TxKcHtdl7UCIk1+V3hvF121CRiQCgwnF5 JwyP3gsv3xzBvADntvAgyfo= =CWnC -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: On Thu, Jan 12, 2006 at 05:40:35PM -, Dave Korn wrote: Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. As far as I can tell by googling, _POSIX_SOURCE, despite the leading underscore, is in fact a user-land feature test macro that it is up to each individual application to decide whether to switch it on or not according to whether the application itself is compliant or not. No need to use google. Just grep for it in /usr/include on linux. Um, I know all about the -A/-B/-C switches that get grep to show you the context around the search match, but I don't know what option switch you pass to grep to get it to show you the semantic meaning of the matched text _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE ... which is equally something that belongs to and is under control of the user's application, and is a way for the user's application to specify (to the compiler, C runtime, and whoever else) that it's compliant and requires/copes with POSIX compliant source in the system header files. So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. I think it means that whoever you were talking to in the IRC channel should have defined _POSIX_SOURCE in their application, and the bug is that they didn't when they should have. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 12:09:59PM -0600, Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. I think it would be the opposite. 1) In glibc, _POSIX_SOURCE is defined by features.h based on a number of conditions[1]. The newlib/Cygwin features.h isn't nearly so thorough. I am going to regret not making that clear, aren't I? 2) After running a grep of /usr/include, it looks like arbitrarily defining _POSIX_SOURCE in Cygwin would cause a significant number of constants and functions to never be defined (and AFAICS there would be no simple way to undef it within code), without actually adding anything, for example: I guess more subtext that you could read into my request would be that we would make the headers work as closely as possible to linux when _POSIX_SOURCE is defined. The key here is to make things look more like linux so that programs port more easily. 3) I think that, in many cases, _POSIX_SOURCE is defined in code if desired (and that would have been the best solution in the aforementioned case). So, that would imply that we really should actively fix up the headers to make sure that it is properly handled. 4) I'm sure I remember a few times that, even when _POSIX_SOURCE was defined in code, I had to #ifndef __CYGWIN__ that define due to compile errors; I can't remember having to manually add such a define, however. I was hoping for concrete examples. Do you have any? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor, le Thu 12 Jan 2006 13:13:39 -0500, a écrit : On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. Then don't ask for your programs to get compiled under other systems than GNU. Defining _GNU_SOURCE without defining _POSIX_SOURCE just means you only target GNU systems. Cygwin is not a GNU system. I'm interested in hearing if this will fix problems with programs which build without problem on linux. Maybe, but it's a really _wrong_ approach which cannot but just degrade cygwin's POSIX compliancy. Regards, Samuel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. cgf But it seems that it only builds without problem on Linux by chance, not by design. I don't see why we should try and fix this in cygwin. Consider how many times people come here and say My app works fine on Linux, how come it just dies with a SEGV on cygwin and someone points out the trivially obvious buffer overrun and we have to explain how it only ever worked on Linux by luck because of differences in the environment and the way the stack is set up. Now, we could put masses of code into cygwin to try and reproduce whatever feature it is of the Linux memory layout that allows these programs to get away with overrunning their buffers and not crash, but I think that would be a deeply silly and overly-complicated attempt to 'help' users with potentially lots of side-effects that would cause problems for everyone, not just writers of buggy programs, and I think that this is an (admittedly less extreme) example of the same thing. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 07:20:21PM +0100, Samuel Thibault wrote: Christopher Faylor, le Thu 12 Jan 2006 13:13:39 -0500, a ?crit : On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. Then don't ask for your programs to get compiled under other systems than GNU. Ok. I won't. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 06:13:16PM -, Dave Korn wrote: Christopher Faylor wrote: _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE ... which is equally something that belongs to and is under control of the user's application, and is a way for the user's application to specify (to the compiler, C runtime, and whoever else) that it's compliant and requires/copes with POSIX compliant source in the system header files. ...which doesn't really invalidate the question of whether cygwin should be trying to set up its headers the same way as linux. So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. I think it means that whoever you were talking to in the IRC channel should have defined _POSIX_SOURCE in their application, and the bug is that they didn't when they should have. Ok. I assumed that some header set _GNU_SOURCE but apparently I was wrong. I should have checked. Just to add even more clarification, this wasn't some guy writing a program for his class assignment. It was someone trying to port a standard linux/unix application. The program had a test for _POSIX_SOURCE which would have worked correctly under Cygwin. I don't know if it was setting _GNU_SOURCE to get this or if the _POSIX_SOURCE test just wasn't discovered by configure. So, maybe this boils down to the question of whether there's something about Cygwin which makes configure think it shouldn't set _POSIX_SOURCE or _GNU_SOURCE. Maybe it is just that uname doesn't return the string linux. Again, I'm not really interested in hearing what someone should have done or should have known to do. If there is a way to make porting a program to cygwin easier without requiring some special knowledge that isn't required on linux, then I'll probably take steps to make that happen. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 06:22:11PM -, Dave Korn wrote: Christopher Faylor wrote: On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. But it seems that it only builds without problem on Linux by chance, not by design. That is by no means clear but even if that was the case, I don't care. I don't see why we should try and fix this in cygwin. Consider how many times people come here and say My app works fine on Linux, how come it just dies with a SEGV on cygwin and someone points out the trivially obvious buffer overrun and we have to explain how it only ever worked on Linux by luck because of differences in the environment and the way the stack is set up. If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. The point of cygwin isn't that it is a place where you find bugs which you should have fixed on linux. Every place where there is a barrier to porting a program from linux to cygwin is YA opportunity for someone to give up in disgust or (maybe worse) send a I get compile error message here. But, I understand your opinion on the matter. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 01:53:50PM -0500, Christopher Faylor wrote: On Thu, Jan 12, 2006 at 06:22:11PM -, Dave Korn wrote: Christopher Faylor wrote: On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. But it seems that it only builds without problem on Linux by chance, not by design. That is by no means clear but even if that was the case, I don't care. I don't see why we should try and fix this in cygwin. Consider how many times people come here and say My app works fine on Linux, how come it just dies with a SEGV on cygwin and someone points out the trivially obvious buffer overrun and we have to explain how it only ever worked on Linux by luck because of differences in the environment and the way the stack is set up. If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. Editing glitch above. Please change '?' to '.'. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. The point of cygwin isn't that it is a place where you find bugs which you should have fixed on linux. Every place where there is a barrier to porting a program from linux to cygwin is YA opportunity for someone to give up in disgust or (maybe worse) send a I get compile error message here. But, I understand your opinion on the matter. I understand yours too, and it's equally valid. I'm curious why someone's application would want to test _POSIX_SOURCE - it should be the app that sets it or not and it should just know. But if they've handed the responsibility to auto* to determine when to use it, and auto* decides YES for Linux, then I agree it should certainly DTST on Cygwin. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 07:06:43PM -, Dave Korn wrote: Christopher Faylor wrote: If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. The point of cygwin isn't that it is a place where you find bugs which you should have fixed on linux. Every place where there is a barrier to porting a program from linux to cygwin is YA opportunity for someone to give up in disgust or (maybe worse) send a I get compile error message here. But, I understand your opinion on the matter. I understand yours too, and it's equally valid. I'm curious why someone's application would want to test _POSIX_SOURCE - it should be the app that sets it or not and it should just know. But if they've handed the responsibility to auto* to determine when to use it, and auto* decides YES for Linux, then I agree it should certainly DTST on Cygwin. This particular application was ircd. It was testing _POSIX_SOURCE (and a few other defines) to determine whether it should use setsid or a two-argument version of setpgrp, e.g.: #ifdef _POSIX_SOURCE setsid (); #else setpgr(..., ...); #endif Again, I should have tested what I was talking about. It turns out that _POSIX_SOURCE *is* turned on by default on in glibc regardless of whether you define _GNU_SOURCE or not. So that would explain why this application built. Apparently _POSIX_SOURCE is turned on by this segment of features.h: #if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) = 500) \ !defined _POSIX_SOURCE !defined _POSIX_C_SOURCE) # define _POSIX_SOURCE 1 # if defined _XOPEN_SOURCE (_XOPEN_SOURCE - 0) 500 # define _POSIX_C_SOURCE 2 # else # define _POSIX_C_SOURCE 199506L # endif #endif The application in question *could* have done things differently but there is no way that this irc user would have been capable of making any changes to accomplish this. I was wondering if anyone had specific examples where defining _POSIX_SOURCE would help or hurt existing applications. I understand that it wouldn't be as simple as just defining _POSIX_SOURCE in a header and then walking away but I'm willing to look into fixing up the cygwin header files to do the right thing (for all I know, they already do) when _POSIX_SOURCE is defined. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: I guess more subtext that you could read into my request would be that we would make the headers work as closely as possible to linux when _POSIX_SOURCE is defined. The key here is to make things look more like linux so that programs port more easily. Right now, all _POSIX_SOURCE seems to do is exclude a number of constants and functions from being defined, supposedly because they aren't part of the POSIX standard. Now, newlib != glibc, but the examples I mentioned before could be compared to their glib counterparts (see below regarding sys/select.h). So, that would imply that we really should actively fix up the headers to make sure that it is properly handled. OK, but I think these are uncommon cases; I've built a *LOT* of packages of all types, and this has not generally been a problem. I was hoping for concrete examples. Do you have any? gmime2: gmime-gpg-context.c: In function `gpg_ctx_op_step': gmime-gpg-context.c:1089: error: `fd_set' undeclared (first use in this function) gmime-gpg-context.c:1089: error: (Each undeclared identifier is reported only once gmime-gpg-context.c:1089: error: for each function it appears in.) gmime-gpg-context.c:1089: error: parse error before rdset gmime-gpg-context.c:1096: error: `rdset' undeclared (first use in this function) gmime-gpg-context.c:1114: error: `wrset' undeclared (first use in this function) gmime-gpg-context.c:1124: error: `wrsetp' undeclared (first use in this function) fd_set is defined in sys/types.h (which is also called by sys/select.h, but only if !defined(_POSIX_SOURCE)), but with this condition: /* We don't define fd_set and friends if we are compiling POSIX source, or if we have included (or may include as indicated by __USE_W32_SOCKETS) the W32api winsock[2].h header which defines Windows versions of them. Note that a program which includes the W32api winsock[2].h header must know what it is doing; it must not call the cygwin32 select function. */ # if !(defined (_POSIX_SOURCE) || defined (_WINSOCK_H) || defined (__USE_W32_SOCKETS)) AFAICS, in glibc, fd_set is (independent of _POSIX_SOURCE) defined via sys/select.h. Since _POSIX_SOURCE on Cygwin doesn't add anything, I can't remember a case that I've had to *add* such a define. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxrujpiWmPGlmQSMRAiZtAKCW/vRO4Ihfop9vJLdKYs0mPvNCgwCfUHh/ 3ziKVCCYkJnGCTnMtgkirec= =bUjT -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 02:27:17PM -0600, Yaakov S (Cygwin Ports) wrote: Christopher Faylor wrote: I guess more subtext that you could read into my request would be that we would make the headers work as closely as possible to linux when _POSIX_SOURCE is defined. The key here is to make things look more like linux so that programs port more easily. Right now, all _POSIX_SOURCE seems to do is exclude a number of constants and functions from being defined, supposedly because they aren't part of the POSIX standard. Now, newlib != glibc, but the examples I mentioned before could be compared to their glib counterparts (see below regarding sys/select.h). Wouldn't that follow from my we would make the headers work as closely as possible to linux? So, that would imply that we really should actively fix up the headers to make sure that it is properly handled. OK, but I think these are uncommon cases; I've built a *LOT* of packages of all types, and this has not generally been a problem. I would not expect that there would ever be a case where defining _POSIX_SOURCE would help you on cygwin since you have discovered that it is not correctly handled in cygwin headers. I was hoping for concrete examples. Do you have any? gmime2: gmime-gpg-context.c: In function `gpg_ctx_op_step': gmime-gpg-context.c:1089: error: `fd_set' undeclared (first use in this function) gmime-gpg-context.c:1089: error: (Each undeclared identifier is reported only once gmime-gpg-context.c:1089: error: for each function it appears in.) gmime-gpg-context.c:1089: error: parse error before rdset gmime-gpg-context.c:1096: error: `rdset' undeclared (first use in this function) gmime-gpg-context.c:1114: error: `wrset' undeclared (first use in this function) gmime-gpg-context.c:1124: error: `wrsetp' undeclared (first use in this function) fd_set is defined in sys/types.h (which is also called by sys/select.h, but only if !defined(_POSIX_SOURCE)), but with this condition: Of course if cygwin uses _POSIX_SOURCE incorrectly it will cause problems. I'm talking about fixing that. Since _POSIX_SOURCE on Cygwin doesn't add anything, I can't remember a case that I've had to *add* such a define. I'm talking about cases where source code to be ported would have ported more easily because it relied on _POSIX_SOURCE turning on some functionality that was available in cygwin (the cygwin header file problems notwithstanding). cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
Hi,
Christopher Faylor, le Thu 12 Jan 2006 13:47:10 -0500, a écrit :
Just to add even more clarification, this wasn't some guy writing a
program for his class assignment. It was someone trying to port a
standard linux/unix application.
If he doesn't define _POSIX_SOURCE for getting function definitions, his
application isn't a standard unix one.
The program had a test for _POSIX_SOURCE which would have worked
correctly under Cygwin. Again, I'm not really interested in hearing
what someone should have done or should have known to do.
Christopher Faylor, le Thu 12 Jan 2006 14:24:23 -0500, a écrit :
This particular application was ircd. It was testing _POSIX_SOURCE (and
a few other defines) to determine whether it should use setsid or a
two-argument version of setpgrp, e.g.:
#ifdef _POSIX_SOURCE
setsid ();
#else
setpgrp(..., ...);
#endif
Testing for _POSIX_SOURCE _doesn't_ make sense. Read a posix book. One
of the first things it would tell you is that you must define
_POSIX_SOURCE yourself for pulling posix function definitions such.
If a programmer wants to determine whether setsid or setpgr can be used,
he can just use an autoconf rule for that. I repeat: read posix, testing
for _POSIX_SOURCE does _not_ make sense in a program.
Christopher Faylor, le Thu 12 Jan 2006 13:53:50 -0500, a écrit :
I don't see why we should try and fix this in cygwin.
Consider how many times people come here and say My app works fine on
Linux, how come it just dies with a SEGV on cygwin and someone points
out the trivially obvious buffer overrun and we have to explain how it
only ever worked on Linux by luck because of differences in the
environment and the way the stack is set up.
If I could easily make cygwin behave exactly the same way so that a
buffer overrun that worked on linux went undetected on cygwin, too, I'd
do that. If there was some linker option to ensure that, I'd use it.
This is /weird/. Reproducing bugs is just silly ! 8!
It turns out that _POSIX_SOURCE *is* turned on by default on in glibc
regardless of whether you define _GNU_SOURCE or not. So that would
explain why this application built.
Apparently _POSIX_SOURCE is turned on by this segment of features.h:
#if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) = 500) \
!defined _POSIX_SOURCE !defined _POSIX_C_SOURCE)
# define _POSIX_SOURCE 1
# if defined _XOPEN_SOURCE (_XOPEN_SOURCE - 0) 500
# define _POSIX_C_SOURCE 2
# else
# define _POSIX_C_SOURCE 199506L
# endif
#endif
Ok, now _this_ makes sense. This is a lazyness of GNU people: gcc
is _not_ an ansi compiler, only gcc -ansi is ; and in that case
__STRICT_ANSI__ is defined for headers to avoid defining things like
_POSIX_C_SOURCE themselves.
Since cygwin uses the gcc compiler, these few lines should _indeed_ be
added to features.h. But not more !
(BTW, that means that ircd can only be compiled with a gcc compiler, not
an ansi compiler).
I was wondering if anyone had specific examples where defining
_POSIX_SOURCE would help or hurt existing applications.
It can hurt:
#include unistd.h
#include stdio.h
#include stdlib.h
static const char *confstr(num)
unsigned int num;
{
static const char *strs[] = { foo, bar, baz };
if (num = sizeof(strs)/sizeof(*strs))
return unknown;
return strs[num];
}
int main(argc, argv)
int argc;
char *argv[];
{
char *conf;
argv++;
while ((conf = *(argv++)))
puts(confstr(atoi(conf)));
return 0;
}
This program is a perfectly valid ansi C program:
$ gcc test.c -o test -ansi -Wall -pedantic
It compiles fine with ansi C compilers.
But it is not a valid posix C program:
$ gcc test.c -o test
test.c:5: error: conflicting types for 'confstr'
/usr/include/unistd.h:544: error: previous declaration of 'confstr' was here
So, does cygwin want gcc to be by default an ansi compiler or a posix
compiler?
Regards,
Samuel
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
