Re: Source file structure for fenv.h support
"Howland, Craig D. - US via newlib" <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
>From: [email protected] <[email protected]> on behalf of Corinna Vinschen <[email protected]> >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