This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libm error handling
- From: Rich Felker <dalias at aerifal dot cx>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 30 Apr 2013 16:05:11 -0400
- 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> <20130430195734 dot B5AB82C08F at topped-with-meat dot com>
On Tue, Apr 30, 2013 at 12:57:34PM -0700, Roland McGrath wrote:
> > 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.
Yes this is a possibility, but I've never seen such a program. If such
programs do exist, the current implementation is treating them
incorrectly; the correct interpretation of such a program as written
is that signgam is an object defined in the application, not libm.
Rich