Re: Source file structure for fenv.h support

[Joel Sherrill <joel at rtems dot org>]

On Tue, Jul 30, 2019 at 1:35 PM Howland, Craig D. - US via newlib <
newlib@sourceware.org> wrote:

> > From: newlib-owner@sourceware.org <newlib-owner@sourceware.org> on
> behalf of Joel Sherrill <joel@rtems.org>
> > Sent: Tuesday, July 30, 2019 12:49 PM
> > To: Howland, Craig D. - US
> > Cc: newlib@sourceware.org
> > Subject: Re: Source file structure for fenv.h support
> >
> > 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?
>      New directory, libc/fenv, would follow present convention.  Yes,
> individual files to make both for less overhead when linking as well as
> being easier to replace each placeholder function with a real one.
>
>
I question libc/fenv since these are supposed to be in libm but agree
on a new subdirectory


> > 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 agree, a non-zero return is sufficient.  I had been thinking about
> returning -ENOTSUP, but -ENOSYS also would convey the intent.  I was
> thinking negative for a general denial, as positives could possibly be
> used in specific implementations to support not-done bits.  (e.g.,
> feclearexcept(FE_OVERFLOW | FE_INEXACT) could return FE_OVERFLOW if it
> failed to clear that bit.)
>      (POSIX has ENOSYS "Functionality not supported." and ENOTSUP
> "Not supported (may be the same value as [EOPNOTSUPP]).", so not clear
> which might be better.  The name NOT SUPported makes better sense to me,
> but being allowed to be the same as "Operation not supported on socket"
> clouds things.  But it really does not matter much what value is used,
> just that it is not 0.)
>      I think it is better if errno is not set, because it is allowed to be
> set non-0 whether or not there is a error for functions which don't
> directly define errno behavior.  (That is, setting it would provide no
> useful portable information, even if it would be useful for Newlib only.)
>

Gotcha. ENOTSUP it is.

In the end, it shouldn't matter as it is just a really bad failure from the
application
perspective.

--joel

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