> errno is stored in Thread Local Storage (TLS). You can't link to the
> global errno anymore.


For a single-threaded process, there is no distinction between thread-local
storage and a global variable. For a multi-threaded process, there is.

The same code can have a different semantic meaning depending upon whether
the process is single-threaded or multi-threaded.

> Using "extern int errno" will actually result in a linking error:
> /usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section
> .tbss mismatches non-TLS reference


My point was simply that there is a difference between single-threaded and
multi-threaded compilation. In one case, 'errno' refers to a variable that
is process global (since there is only one thread). In the other case, it
does not.

That these two different semantics are implemented by the same code doesn't
change the fact that the semantics are different. In fact, it makes the
important point that the semantics of code can be changed by whether the
process is single-threaded or multi-threaded.

On many Linux distributions, it is perfectly acceptable to do the following:

#ifdef _REENTRANT
// inefficient thread-safe code
#else
// more efficient code that assumes 'errno' is process-global
#endif

This is because many distributions only guarantee POSIX compliance if you
specify '-pthread' and '-pthread' always defines _REENTRANT.

You have to follow the rules if you want the platform to follow the rules.

DS


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org