This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 6/8] float128: Expose _Float128 finite math functions.
- From: "Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 3 Mar 2017 17:17:00 -0300
- Subject: Re: [PATCH 6/8] float128: Expose _Float128 finite math functions.
- Authentication-results: sourceware.org; auth=none
- References: <1478716859-3246-1-git-send-email-gftg@linux.vnet.ibm.com> <1478716859-3246-7-git-send-email-gftg@linux.vnet.ibm.com> <alpine.DEB.2.20.1611092204000.6428@digraph.polyomino.org.uk>
On Wed, 9 Nov 2016 22:05:57 +0000
Joseph Myers <joseph@codesourcery.com> wrote:
> Rather than a load of repetitive boilerplate, the function declarations
> here should be macroized, with only the definition of the macros depending
> on __USE_ISOC99, __MATH_DECLARE_LDOUBLE, __NO_LONG_DOUBLE_MATH and
> float128 presence etc. (for most functions, maybe obsolete and lgamma ones
> are more complicated).
>
My attempts to macroize the function declarations were a bit
frustrating. While some of the declarations follow a nice pattern
(always declare for double; always declare for float when __USE_ISOC99;
declare for long double based on __USE_ISOC99, __MATH_DECLARE_LDOUBLE,
and __NO_LONG_DOUBLE_MATH), when that is not the case, the declarations
are somewhat less clear and trickier to read, imo.
For instance:
For exp10 and pow10, the float version is declared *even* when
__USE_ISOC99 is not. This means that I cannot create a macro that
*always* checks for __USE_ISOC99 to declare the float version.
Otherwise, I need to declare the float versions of exp10 and pow10
without using such macro. I find it less clear [to declare some
functions using macros, while others without] than current code.
Another option would be to create this macro not dependent on
__USE_ISOC99, but then it defeats the purpose [of making the macros
dependent on __USE_ISOC99], which you suggested.
I would like to keep this patch as is for the next iteration of this
series... Would you be fine with that? Or maybe you had something
else in mind and I was not able to grasp.
Thanks,
Gabriel