Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 04 Jan 2022 15:19:48 +0100
From: Paul Zimmermann <>
To: Rich Felker <>
Subject: Re: correctly rounded mathematical functions

       Hi Rich,

> License: should be licensed under something permissive and
> MIT-compatible, preferably explicitly MIT if you'll be
> dual-/multi-licensing anyway.

ok, we'll consider multi-licensing with MIT.

> Table size: main consideration is that tables need to be pure
> shareable rodata, so no runtime generation of contents or pointers in
> contents. Failure to follow this would produce significant cost in
> *all processes* even ones that don't use the cr_* functions. I would
> hope they'd also fit in a few tens of kB of rodata, but I don't know
> how realistic that is.

tables so far are "static const"

> Allowed operations: I'm not sure what the scope of this question is.
> Are you asking if things like changing rounding mode would be okay? Or
> something else. musl implements C11 and hopefully future versions of
> the language library, but is implemented in C99 (+ very minimal set of
> common/"GNU C" extensions), so code to be included in musl shouldn't
> depend on new language features or compiler extensions not already
> used (at least without checking on them first). We also have
> softfloat-only targets and targets with excess precision, so code
> should be compatible with those (which means not depending on changing
> fenv; see commit 4f3d346bffdf9ed2b1803653643dc31242490944 for an
> example of where this came up).

we avoid playing with fesetround/fegetround since in general this makes
the code slower

> > We have started to work on two functions (cbrt and acos), for which we
> > provide presumably correctly rounded implementations (up to the knowledge
> > of hard-to-round cases) [2].
> > 
> > Christoph Lauter
> > Jean-Michel Muller
> > Alexei Sibidanov
> > Paul Zimmermann
> > 
> > [1]
> > [2]
> Is there a standalone version of the code where it can be read in full
> not as a patch to glibc? Is the code being developed in such a way
> that it's not potentially a derivative work of the glibc versions?

yes there are several standalone versions of the code (entries marked "full"

Best regards,

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.