435. bug in DR 25

Section: 27.4.4.4 [string.io] Status: CD1 Submitter: Martin Sebor Opened: 2003-10-15 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [string.io].

View all issues with CD1 status.

Discussion:

It has been pointed out that the proposed resolution in DR 25 may not be quite up to snuff:
http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html

It looks like Petur is right. The complete corrected text is copied below. I think we may have have been confused by the reference to 22.2.2.2.2 and the subsequent description of `n' which actually talks about the second argument to sputn(), not about the number of fill characters to pad with.

So the question is: was the original text correct? If the intent was to follow classic iostreams then it most likely wasn't, since setting width() to less than the length of the string doesn't truncate it on output. This is also the behavior of most implementations (except for SGI's standard iostreams where the operator does truncate).

Proposed resolution:

Change the text in 21.3.7.9, p4 from

If bool(k) is true, inserts characters as if by calling os.rdbuf()->sputn(str.data(), n), padding as described in stage 3 of lib.facet.num.put.virtuals, where n is the larger of os.width() and str.size();

to

If bool(k) is true, determines padding as described in lib.facet.num.put.virtuals, and then inserts the resulting sequence of characters seq as if by calling os.rdbuf()->sputn(seq, n), where n is the larger of os.width() and str.size();

[Kona: it appears that neither the original wording, DR25, nor the proposed resolution, is quite what we want. We want to say that the string will be output, padded to os.width() if necessary. We don't want to duplicate the padding rules in clause 22, because they're complicated, but we need to be careful because they weren't quite written with quite this case in mind. We need to say what the character sequence is, and then defer to clause 22. Post-Kona: Benjamin provided wording.]