This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv3 2/3] Refactor tst-strtod-round.c for type-generic-ness
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 24 May 2016 15:25:43 +0000
- Subject: Re: [PATCHv3 2/3] Refactor tst-strtod-round.c for type-generic-ness
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1464041464 dot git dot murphyp at linux dot vnet dot ibm dot com> <8e5e98006235dcad1d036d3e71e51615cfd79286 dot 1464041464 dot git dot murphyp at linux dot vnet dot ibm dot com>
On Mon, 23 May 2016, Paul E. Murphy wrote:
> +/* Define the long double choose (LDC) macro
> + to select the appropriate generated long double
> + value from the generated test data. */
> +#if LDBL_MANT_DIG == 53 && LDBL_MAX_EXP == 1024
> +/* This is for the long double == double format. */
> +# define LDC(a, ...) a
> +/* This macro is used in conjunction with the output from the
> + gen-tst-strtod-round utility to select the appropriately
> + rounded long double value for a given format. */
> +#define TEST(s, \
> +struct test_exactness
> + {
> + STRUCT_FOREACH_TYPE ()
> + };
> +
> +struct test_results
> + {
> + STRUCT_FOREACH_TYPE ()
> + };
> +
> +struct test {
> + const char *s;
> + struct test_exactness exact;
> + struct test_results r[4];
> +};
All this code seems extremely specific to the tst-strtod-round test. I
think it belongs there, not in a header that's supposed to be about common
code for making multiple strtod tests type-generic.
I think the only code this patch adds to tst-strtod.h that clearly belongs
there is the definition of STRUCT_FOREACH_TYPE. Even the rounding mode
handling seems very specific to tst-strtod-round (to the extent of having
a comment about "This test").
Also, struct test_exactness previously had all its elements bool. By
making it use STRUCT_FOREACH_TYPE you're giving floating-point types to
what are logically booleans, which I don't think is appropriate.
--
Joseph S. Myers
joseph@codesourcery.com