Re: arm fenv support - static inline of methods

[Joel Sherrill <joel.sherrill@gmail.com>]

On Wed, May 13, 2020 at 1:36 PM Brian Inglis <
Brian.Inglis@systematicsw.ab.ca> 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.]
>