Re: More instantiation problems under hpux

[Benjamin Kosnik <bkoz at redhat dot com>]

> | It was decided that the built C++ limits header should match the C
> | limits header not the actual FP hardware (the fact that the C limits
> | header provided by an OS doesn't match the hardware might be
> | considered a bug).  Under this observation, it must be understood that
> | they are the published "worst-case" limits *(i.e. should be read as
> | "you might not be able to store an FP with more precision or range"
> | not "you will never see an FP value with more precision and/or range")
> | the absolute limits that will be seen in all cases.*  The best example
> | I can offer is FreeBSD running on i386.  By default, it is possible to
> | get a float or double with far more precision and range than in the
> | published header file unless it has been written to memory (in which
> | case, by default, it is truncated to the published limits).  Of
> | course, when this happens depends on compiler switches and exact code
> | paths, etc.
> 
> [ Emphasis added ]
> 
> This description is a perfect transcript of the philosophy behing the
> limit-thingies. 

Ahh. Maybe it should be added then as a comment...

> Yes, on one hand I think operator>>() should refuse to return any
> value outside publised limits for conformance reasons, and on the
> other hand I think it /could/ be useful for some very special tasks
> (e.g. system programming or such) to be able to get values beyond the
> official limits if the hadware can handle them.  The latter option
> should then be providded as an extension.  Benjamin, what is your take?

Probably not.

Ok, to clarify, Gaby. My wording was way off, and causing confusion.

Currently the numerics inserters/extractors use limits properties to 
determine when to stop inserting and extracting. When one past the maximum 
number of digits is reached, failbit is set on the stream. 

Setting failbit is required: what the maximum number of digits are is 
somewhat vague. 

It seems like, if limits is going to take a conservative approach, then 
the insertion/extraction code can still use this general philosophy, and 
the testsuites can reflect it. Since I developed them on x86/linux, where 
the limits == FP limits, they are too strict.

> The issue is that when a new testcase was added, it assumed the built 
> limits header file described the FP hardware limits perfectly.

Right. Instead, it should reflect the more conservative "C" headers. 

-benjamin