Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 23 Feb 2020 01:25:13 -0500
From: Rich Felker <>
Subject: Re: Considering x86-64 fenv.s to C

On Sun, Feb 23, 2020 at 04:41:31PM +1100, Damian McGuckin wrote:
> On Sat, 22 Feb 2020, Rich Felker wrote:
> >First comment: I couldn't find (maybe I missed?) what you intend fore
> >the contents of fenv-generic.c and fenv-trivial.c to be, but I don't
> >see what you want them for. fenv.c should just use the macros/inlines
> >the fenv_arch.h defines, naturally collapsing to empty functions when
> >they do nothing (for softfloat archs).
> I agree. I was seduced by what I thought was a better way.
> I assume that I can also have a
> 	fenv_arch_soft_float.h

I don't follow what this would be for. Presumably
arch/generic/fenv_arch.h would be empty and the internal header that
includes fenv_arch.h would define dummy fenv accessor helpers in the
absence of any defined by fenv_arch.h, or similar.

> and
> 	fenv_arch_common_fpu.h
> Each of thes is pulled in at the end of fenv_arch.h for respectively
> a)	those machines with a generic soft_float architecture
> b)	those machines with non-Intel (hard) FPUs.

Other way around. fenv_impl.h (this would probably be the right name
according to existing patterns in musl) would include fenv_arch.h and
then define defaults for anything not defined by the latter. Then
source files don't include fenv_arch.h at all, only fenv_impl.h.

Ordering the inclusion this direction keeps duplicate logic out of
arch-specific files.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.