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

[Joseph Myers <joseph at codesourcery dot 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