Source file structure for fenv.h support

[Howland, Craig D. - US via newlib]

>From: newlib-owner@sourceware.org <newlib-owner@sourceware.org> on behalf of Corinna Vinschen <vinschen@redhat.com>
>Sent: Tuesday, July 30, 2019 3:37 AM
>To: Joel Sherrill
>Cc: Newlib; Vaibhav Gupta
>Subject: Re: Source file structure for fenv.h support
>
>On Jul 29 13:48, Joel Sherrill wrote:
>> Hi
>>
>> Vaibhav is looking at porting *BSD fenv support for a few more
>> architectures. Right now, it looks like there is only SPU and RISC-V
>> support with this structure:
>>
>> - libc/machine/ARCH/include/fenv.h - portable POSIX interface, includes
>> sys/fenv.h
>> - libc/machine/ARCH/include/sys/fenv.h - architecture specific details.
>>
>> I think (but have not confirmed) that the RISC-V version is correct per
>> POSIX. The SPU version clearly is not as it does not have the right
>> signature for most of the methods as they all are supposed to return int
>> and not void.
>>
>> My proposal is to verify the RISC-V include/fenv.h is POSIX correct and
>> then move it to libc/include/fenv.h.For completeness, we may need a
>> minimal, non-functional sys/fenv.h which defines dummy fexcept_t and fenv_t
>> structures.  But it becomes the responsibility of a port to provide
>> <sys/fenv.h> and implementations.
>>
>> In the event a port provides the entire implementation as inlines, it can
>> override fenv.h.
>>
>> Does this make sense? Is it a good approach? I want to avoid duplicating a
>> pure POSIX version of fenv.h like RISC-V has.
>
>Sounds good to me, but please don't forget the Cygwin version of fenv.h.
>It's sys parts are basically the x86/x86_64 variation of the same, and
>it's pretty complete, including glibc-only and BSD-only functions.
>
>
>Corinna
--------------------------------------------------------------------------------
     I think the proposal is one fairly-trivial step short.  As noted, very 
few architectures have support for it, but only "a few more" are planned to 
be added.  For there to be a base libc/include/fenv.h, there also need to be
default functions which return an error.  Lacking that, there probably should
not be a default libc/include/fenv.h.  (Perhaps there could be a default 
sys/env.h with a #error in it, but stub error-returning functions would be
better.)
                                Craig