Re: [PATCH] newlib: switch to autoconf long double wider macro

On 1/21/22 16:44, Mike Frysinger wrote:
> On 21 Jan 2022 12:03, C Howland wrote:
> And a question about the test. There are two main segments in it:
>> +           long double const a[] =
>> +             {
>> +                0.0L, DBL_MIN, DBL_MAX, DBL_EPSILON,
>> +                LDBL_MIN, LDBL_MAX, LDBL_EPSILON
>> +             };
>> +           long double
>> +           f (long double x)
>> +           {
>> +              return ((x + (unsigned long int) 10) * (-1 / x) + a[0]
>> +                       + (x ? f (x) : 'c'));
>> +           }
>> +
>> +int
>> +main ()
>> +{
>> +static int test_array [1 - 2 * !((0 < ((DBL_MAX_EXP < LDBL_MAX_EXP)
>> +                  + (DBL_MANT_DIG < LDBL_MANT_DIG)
>> +                  - (LDBL_MAX_EXP < DBL_MAX_EXP)
>> +                  - (LDBL_MANT_DIG < DBL_MANT_DIG)))
>> +           && (int) LDBL_EPSILON == 0
>> +         )];
>> +test_array [0] = 0;
>> +return test_array [0];
>> +
>> +  ;
>> +  return 0;
>> +}
>>
>> What's the first part doing?  Only the second part (main) is performing the
>> size comparison.

The first part is making sure you can use macros like DBL_MIN where 
constant expressions are required. Some old nonstandard compilers don't 
support that.


>>       Now a secondary item:  the (int) LDBL_EPSILON == 0 term in the check
>> is degenerate and does nothing.  (By rule (from the standard) the cast to
>> int discards the fraction so it will always be 0 and it becomes ... && 1.)


That's true on standard compilers. But there may be old nonstandard 
compilers where (int) LDBL_EPSILON == 0 is not an integer constant 
expression, and that part detects the bug in those compilers.