Re: arm fenv support - static inline of methods

Joel Sherrill via Newlib <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <CAF9ehCVo6t5GrTwj1A2hpsZRAJKmDRW4pOFiNnGjxsR6i5RVvw@mail.gmail.com>
On Wed, May 13, 2020 at 1:36 PM Brian Inglis <
[email protected]> wrote:

>
> On 2020-05-13 12:22, Joel Sherrill wrote:
> > On Wed, May 13, 2020 at 1:17 PM, Brian Inglis wrote:
> >> On 2020-05-13 08:11, Joel Sherrill wrote:
>
> >>> Eshan Dhawan is an RTEMS GSoC 2020 student working on adding more POSIX
> >>> methods to RTEMS and newlib if appropriate. He is currently looking at
> >>> adding more
> >>> fenv.h implementations.
> >>>
> >>> The FreeBSD implementation of arm fenv.h has static inlines for all the
> >>> methods in sys/fenv.h. Is this OK? Or should they be turned into real
> >>> bodies in a C file?
>
> >> Don't all functions need to be provided as linkable implementations for
> >> cases where they are invoked using their address directly or indirectly,
> >> unless the standards agree they don't need to be?
>
> > That's what I think also but that's not how FreeBSD has implemented it.
> > IMO the static inline implementations from them need to move to .c files.
>
> I'm pretty sure I've seen somewhere in the sources, that the library has a
> standard approach for doing this, as most libraries do for such common
> cases.
>

Thanks for saying that. It just occurred triggered me to realize that this
in the
header file:

#ifndef __fenv_static
#define __fenv_static static
#endif

All we need is an arm fenv.c which does this

#define __fenv_static
#include <fenv.h>

Then magically, we have methods (I think).

And empty files for every fenv source file named for a method since
all the methods are in one file.

Thank you. I think that's enough to let me help Eshan through this.

--joel

-- 
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in IEC units and prefixes, physical quantities in SI.]
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.