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 17:35:24 -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> <20130430200511 dot GH20323 at brightrain dot aerifal dot cx> <20130430205519 dot C86632C088 at topped-with-meat dot com>
On Tue, Apr 30, 2013 at 01:55:19PM -0700, Roland McGrath wrote:
> > 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.
>
> No, that's just not what the API is (and has always been).
Are you claiming that, at one time, the documented API was that you
define _your own_ variable named signgam and lgamma writes into it? If
not, then I think it's reasonable to say programs doing this are being
interpreted wrong under the current implementation. Even if there were
historically no obligation on implementations (since C89 did not have
the lgamma function) to avoid stepping on the application's namespace,
if the historical lgamma function defined its own (non-weak) signgam
with external linkage, then defining in the application an external
symbol by the same name would invoke undefined behavior whenever
lgamma is linked. As such, I think, either way, it's well-justified to
call programs using their own "int signgam;" with lgamma broken.
Rich