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