This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: TS 18661-3 and related floating-point interfaces


On Tue, Jan 17, 2017 at 8:50 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Tue, 17 Jan 2017, Zack Weinberg wrote:
>>
>> ... which should be changed as necessary to reflect the principle that
>> new math functions do not set errno.  Math functions setting errno was
>> a design mistake which should not be continued.
>>
>> If you disagree with this principle, please give a concrete reason
>> _other than_ continuity.
>
> I don't think it's a design mistake.  It's the normal approach for
> indicating errors in C library functions in glibc in general, and the only
> way they can indicate errors when exceptions aren't supported.

Yes, but math is different.  First, for math functions, the documented
errno codes (EDOM, ERANGE) are fully redundant to the IEEE in-band
error values (+/-Inf and NaN); there's never any reason to look at the
errno code once you've noticed the in-band error.  (IEEE floating
point exception flags provide slightly more detail, but in my limited
experience it isn't _useful_ detail.)  Second, math functions are
subject to more potential optimization (most importantly inlining and
vectorization, but CSE, code motion, and constant folding may also be
relevant) than anything else that can set errno, and needing to set
errno interferes with all of those optimizations.  Third, because
people don't think about the possibility of math functions clobbering
errno, they can interfere with reliable error handling for other
operations (I have actually tripped over a case where a complicated
network client tried to dump out a bunch of internal debugging info on
a socket error, which involved, IIRC, a call to log10() on a number
that happened to be negative (because of another bug), and boom: the
error code I actually wanted to see was lost.  Yes, that was a bug in
the program.  It was still the last straw at the end of a long and
painful week of debugging.)

I'd actually like to see us bump all the libm symbol versions and make
the default behavior of _all_ the math functions be to set _neither_
errno nor IEEE exception flags (i.e. math_errhandling=0); requiring
the use of -f options and/or FENV_ACCESS pragmas to turn either of
them _on_.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]