[v3] DR 282 and libstdc++/4402

[Benjamin Kosnik]

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?

The question of maximum/minimum lengths for numeric output/input is
relevant
because I'm about to start on libstdc++/3720, which is the opposite of
4402, namely input as opposed to output. I've been trying to make sure
that output via a particular facet can be read by the same facet's input
facilities (call me crazy!). This isn't always possible (thanks to __fill
parameters) but non-filled output should always be possible to parse, I
think.

So, the length issue needs to reach satisfactory closure. Nathan, can you
weigh in please? Why __max_exp and __max digits + 4?

With this the numerics output for floating point types deals with
grouping. Input already deals with grouping, so that was a non-issue.

I'd appreciate people trying to break this code. It should be pretty
bulletproof for gcc-3.1.

tested x86/linux.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.20011205-1
Type: application/octet-stream
Size: 8535 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20011205/ca6172ab/attachment.obj>