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/
