This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: TS 18661-3 and related floating-point interfaces
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 17 Jan 2017 13:26:09 +0000
- Subject: Re: RFC: TS 18661-3 and related floating-point interfaces
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1701162328090.3481@digraph.polyomino.org.uk> <CAKCAbMh-XPPLUf84O=zrFEutrEA9epmx13YWDxedaQqFTrsTqw@mail.gmail.com>
On Mon, 16 Jan 2017, Zack Weinberg wrote:
> > Any comments on this proposal regarding inclusion of TS 18661-3
> > functions and similar functions for the new types in glibc?
>
> New math functions should not set errno.
New functions should set errno in accordance with the documented error
handling conventions and the value of math_errhandling, just like existing
functions. (I expect completely new functions, e.g. from TS 18661-4, as
opposed to existing functions for new types, would generally handle errno
setting directly, rather than using separately built wrappers, so the
implementations generally only need to check for each error condition
once.)
(Ideally math_errhandling would reflect -fno-math-errno,
-fno-trapping-math and architectures lacking exceptions support, with the
caveat that if you have -fno-math-errno together with -fno-trapping-math,
or -fno-math-errno on an architecture lacking exceptions support, this is
not a conforming configuration because at least one error-handling
mechanism must be supported; in such a non-conforming case you could
either leave math_errhandling undefined as done at present for
__FAST_MATH__, or define it to the non-conforming value 0.)
--
Joseph S. Myers
joseph@codesourcery.com