Re: [patch] For BZ #17328, mark __errno_location with __attribute__((returns_nonnull)) for gcc >=4.9.0

[Roland McGrath <roland at hack dot frob dot com>]

> ... so I gotta wonder if it mightn't be a better use of people's time
> to make errno a proper thread-local variable instead.  What's blocking
> that?

That's what it already is internally.  It's never been part of the public
API or ABI.  I think that's primarily because we started using TLS
internally for errno when TLS use and support was still quite new, and we
did not want to complicate matters for users.  

Nowadays with some appropriate compiler-version checks it would probably be
fine to let users see the errno symbol.  But I'm still hesitant to make the
change by default, because it would make approximately every single
application everywhere a participant in the ELF TLS ABI.  I tend to think
it's better that a program where no TLS variables were used explicitly does
not use any of the TLS ABI at all.

Something that we could consider as a middle road is exporting errno with a
proper symbol version (it's currently GLIBC_PRIVATE, which nothing residing
outside the libc source tree should ever use) and then having errno.h do:

	extern __thread int errno;
	#define errno (*__errno_location ())

Then a savvy user could '#undef errno' to use the TLS version.  We could
also make the macro conditional on some predefine that -fsanitize=undefined
provides.  I would be fine with doing something like this now, though for
at least the next release cycle I would still argue against making the TLS
declaration be what programs compiled in normal ways see by default.


Thanks,
Roland