Re: Source file structure for fenv.h support

[Joel Sherrill <joel at rtems dot org>]

On Tue, Jul 30, 2019 at 11:05 AM Howland, Craig D. - US via newlib <
newlib@sourceware.org> wrote:

> >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.)
>

Good idea. Put them in libm/math as individual files?

Looking at opengroup.org, it looks like returning a non-zero number is
sufficient. No errno's are defined. We could also set errno=ENOSYS
if you like.

I will try to put together a stub and header file proposal patch for
discussion.

--joel


>                                 Craig
>