[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multithread CPPFLAGS
From: |
Matthew Woehlke |
Subject: |
Re: multithread CPPFLAGS |
Date: |
Mon, 25 Aug 2008 12:40:07 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.16) Gecko/20080723 Fedora/2.0.0.16-1.fc9 Thunderbird/2.0.0.16 Mnenhy/0.7.5.0 |
Bruno Haible wrote:
Yoann Vandoorselaere wrote:
- it does not need to see a thread-aware errno,
hence it does not need to compile with THREADCPPFLAGS.
Not using a thread-aware errno from an application that indirectly use
thread through a library (which use thread-aware errno). Are you
completely sure this is safe?
Instead of discussing whether I'm "completely sure" and what we can "assume",
can you show a test program that decides the question without any doubt?
No, because such a test program would have to be run on all supported
porting targets to confirm that there is no problem (while a failure
anywhere confirms that there is a problem)... assuming the test is
exhaustive, which it may well not be. (I guess you could incorporate
such a test into the configuration suite, which would mitigate the
platform coverage issue.)
I wrote a short test (below), it seems to work on Solaris, and from what
I can tell, GNU does not have an 'extern int errno' (i.e. the function
is always used), but that's hardly exhaustive coverage.
$ cat prog.c
#include <errno.h>
#include <stdio.h>
extern void foo();
void bar() {
fprintf(stderr, "errno = %i (%s)\n", errno, strerror(errno));
}
int main() {
fprintf(stderr, "in prog, &errno = %lx\n", &errno);
errno = EINVAL;
bar();
foo();
bar();
}
$ cat lib.c
#include <pthread.h>
#include <errno.h>
#include <stdio.h>
void foo() {
fprintf(stderr, "in lib, &errno = %lx\n", &errno);
errno = EIO;
}
$ cat Makefile
all: prog lib
prog: prog.c lib
cc -o test -L. -ltest prog.c
lib:
cc -G -o libtest.so -D_REENTRANT -lpthread lib.c
clean:
rm test libtest.so prog.o lib.o
--
Matthew
Person A: It's an ISO standard.
Person B: ...And that means what?
--mal (http://theangryadmin.blogspot.com/2008/04/future.html)
- Re: Lock module improvement, (continued)
- Re: Lock module improvement, Bruno Haible, 2008/08/18
- Re: Lock module improvement, Yoann Vandoorselaere, 2008/08/18
- Re: multithread CPPFLAGS, Bruno Haible, 2008/08/20
- Re: multithread CPPFLAGS, Yoann Vandoorselaere, 2008/08/21
- Re: multithread CPPFLAGS, Bruno Haible, 2008/08/21
- Re: multithread CPPFLAGS, Yoann Vandoorselaere, 2008/08/21
- Re: multithread CPPFLAGS, Matthew Woehlke, 2008/08/21
- Re: multithread CPPFLAGS, Yoann Vandoorselaere, 2008/08/25
- Re: multithread CPPFLAGS, Bruno Haible, 2008/08/25
- Re: multithread CPPFLAGS, Yoann Vandoorselaere, 2008/08/25
- Re: multithread CPPFLAGS,
Matthew Woehlke <=
- Re: multithread CPPFLAGS, Ralf Wildenhues, 2008/08/26