Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Mar 2012 09:04:59 -0500
From: Rich Felker <>
Subject: Re: libm

On Mon, Mar 05, 2012 at 09:51:35AM +0100, Szabolcs Nagy wrote:
> > > i wrote it using generic since i couldnt come up with
> > > any way to solve it in c99
> > 
> > There's no way to solve it in C99 matching the return types, but if
> > you don't care about return types, it's pretty easy (albeit ugly and
> > verbose) with ?: conditionals based on sizeof(x).
> > 
> hm i haven't even thought about return types
> my problem was calling the double version of a function when the
> arg is integral and the float version when the arg is float.
> (it can be done with sizeof if we can assume there is a larger
> integer type than float, but i thought that was ugly)

Hm? If you need a macro to test whether an argument is an integer or
floating point, try this:

#define __IS_FP(x) !!((1?1:(x))/2)

No assumptions at all.

> even if we don't care about return types and int arguments
> it seems tgmath is very ugly

Yes, it is ugly. I don't think there's any way around the fact that
tgmath.h is ugly.

> > > complex is missing but it is not hard to add
> > > (if you want to wait for it)
> > 
> > Either way.
> > 
> > > the parts i wrote may need some review or testing
> > > (it can be done after merging of course)
> > 
> > Yes, I'm okay with that.
> > 
> i can do the merge and then you git pull
> or you can do it from libm
> the long double ifdefs needs to be fixed
> and math.h sorted out

I can do it, but might be another day or two. Feel free to keep fixing
stuff up in the mean time if you have time. :)

> > There's the libc-testsuite git repo, and then cluts. Neither is
> > musl-specific. The former is much broader in scope; the latter is
> > probably more intensive in the few areas it tests.
> > 
> i know but i'm not content with either of those
> imho there should be one libctest repo which is a bit more
> organized than libc-testsuit and contains the cluts tests
> as well
> > > ok so using compound literal
> > > i was thinking about this
> > > something like this will work
> > 
> > OK.
> > 
> i saw that you removed the compound literal definition of
> NAN, INFINITY etc from math.h
> if we want to keep the headers c89 friendly then
> isnan, isinf,.. cannot be defined without function call
> maybe use static __isnanf,.. functions?

The removal has nothing to do with c89; it's actually the fact that
the compound literal definition was not a constant expression and the
standard requires these macros to expand to constant expressions.

As far as I know, gcc allows the compound literal even in old-standard
modes, probably because it was a feature of "GNU C" long before C99
adopted it. In any case I see no good way to define them without
compound literals except the function calls..

> > The semantics should only be changed if the goal is to consider
> > NAN/INF as "large" values too. Of course you also get abs() for free
> > using the representation and bitmask. Otherwise, for finite
> > comparisons comparing the representations and comparing the
> > floating-point values should have the same behavior.
> > 
> hm but float compare will compile to different instruction
> so there is at least performance difference

Yes. In principle it would be faster to do everything as floating
point so no store/load delays are needed. In relality I doubt it makes
much of a difference. In almost all of these functions the actual
computation time dominates.


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.