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)
