This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libm error handling
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, <libc-alpha at sourceware dot org>
- Date: Tue, 30 Apr 2013 12:57:34 -0700 (PDT)
- Subject: Re: libm error handling
- References: <Pine dot LNX dot 4 dot 64 dot 1304301628510 dot 21969 at digraph dot polyomino dot org dot uk> <20130430181544 dot GG20323 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1304301910460 dot 28945 at digraph dot polyomino dot org dot uk>
> Maybe you need symbol versioning to separate the old version of lgamma
> that writes to signgam for old binaries, and the new one that writes to
> __signgam for new binaries.
I think that is the best you can do. But it's still not very satisfactory
for the usual expectation of recompiling old sources: either they work as
before, or you get some complaint. If old sources say "int signgam;"
instead of "extern int signgam;" they will silently change from getting
values in signgam to it always staying its initial zero. We can document
that of course, but I can't think of anything we can do to ensure that such
new compilations get an error or warning.
I guess they could get a runtime warning if we add an
"if (&signgam != &__signgam)" check in an initializer function somewhere.
But that's lukewarm comfort at best.
Thanks,
Roland