This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] DR 282 and libstdc++/4402


Benjamin Kosnik wrote:

> Here's what I'm going to check in. I believe this resolves the DR and
> GNATS report to everybody's satisfaction. Please correct me if I'm wrong.
>
> I confess to still being a bit in the dark as to maximum and minimum
> expected output/input of floating point types. In particular, I don't
> understand how these lengths are computed:
>
> !       // Consider the possibility of long ios_base::fixed outputs
> !       const bool __fixed = __io.flags() & ios_base::fixed;
> !       const int __max_exp = numeric_limits<_ValueT>::max_exponent10;
> !       // XXX Why + 4? Why * 4? What's going on? Who's on first?
> !       const int __cs_size = __fixed ? __max_exp + __max_digits + 4
> !                                     : __max_digits * 4;
>
> I removed the extended checks for __fixed because I think they are not
> relevant. Paolo?

I Benjamin! If I can express my personal opinion you have done an incredibly good
job!

As regards the lengths. This is how I reasoned. I hope we all agree on this.

The first possibility is for __fixed: in that format you may have a (possibly) very
long series of figures before the point (up to the maximum exponent + 1) + sign +
decimal point + the fractional part (as many figures as __max_digits) + '\0'.
Example: for __max_exp = 5 and __max_digits = 3, the longest string is
+999999.999{\0}

Notice that on machines with 128 bit long doubles, __max_exp may by up to 4932,
that's way I had considered the short-fixed as a separate case. In fact, as a limit
for the short case I choosen something like 1e+35. Why? Because, roughly speaking, it
is usually considered "sensible" to print in fixed format numbers with a size not
bigger than __max_digits (consider, f.i., the criterion which libc uses to to switch
automatically between %f and %e for the %g format). Now digits10, on 128 machines is
about 33, so 35 is on the safe side.
In that case, that of fixed format with a size < 1e+35 we can still have up to
__max_digits digits for the fractional part, and therefore about 3*__max_digits chars
overall. To be safe, I had choosen 4*__max_digits.

But if you do not deal with the short-fixed case separately from the general fixed
case and together with the non-fixed case, as you do in your final patch, there is no
reason at all, IMO, to have __max_digits*4 for the non-fixed case, since that was a
size dictated by the short-fixed case not by the non-fixed case by itself. For the
common non-fixed case,  __max_digits*2, the current value, is perfectly ok, IMO.
Perhaps __max_digits*3, just to be safe. Unbreakable, as you say.

So, what else can I add?
I'm a just little bit nervous for the prospect of __builtin-alloca-ting about 5000
chars for *any* long double fixed output on Sparc64, for instance, otherwise,
great!!!

Cheers,
Paolo.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]