This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Source file structure for fenv.h support
> 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.
>
> 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.)
>
> I will try to put together a stub and header file proposal patch for
> discussion.
>
> --joel
Craig