Re: 18/numeric_limits fail on solaris 2.8

[Paolo Carlini <pcarlini at unitus dot it>]

Hi Benjamin, hi all,

I'm having a look at this failure on solaris and many things look very 
strange to me. The following is line 91, the first assert failing:

 > VERIFY( (extrema_max - limits_max) < (1 + epsilon) );

I suppose there is a typo in your transcript, right? ;-)
Because I have:

VERIFY( (extrema_min - limits_min) < epsilon );
VERIFY( (limits_min - extrema_min) < epsilon );
VERIFY( (extrema_max / limits_max) < (1 + epsilon) );
VERIFY( (limits_max / extrema_max) < (1 + epsilon) );

Anyway, in this kind of test it seems to me in order an abs(), like:

VERIFY( abs(extrema_min - limits_min) < epsilon );
VERIFY( abs(limits_min - extrema_min) < epsilon );
VERIFY( abs(extrema_max / limits_max) < (1 + epsilon) );
VERIFY( abs(limits_max / extrema_max) < (1 + epsilon) );

But, of course, this is not the real reason the test is failing: you 
report /very/ weird things later:

 > (gdb) p limits_min
 > $1 = 1.3906711615670008644313954483327525e-309
 > (gdb) p extrema_min
 > $2 = 1.1519648082658484611329186009243131e-19
 > (gdb) p extrema_max
 > $3 = 35740566642812252160
 > (gdb) p limits_max
 > $4 = nan(0xeffffffffffff)

How possibly limits_min can be so different from the value expected for 
a 128 bit platform, that is ~ 3.36e-4932 ?? This is instead the typical 
value of a 64 bit platform!

Also extrema_min is not ok: it should be identical, by definition, to 
LDBL_MIN, right? Instead, is very big, similar to what I would expect 
for epsilon!

extrema_max and limits_max are /completely/ crazy...

Is there any chance you can double-check all of this again before the 
release?

Ciao, Paolo.