NUL chars in formatted and unformatted string I/O

[Phil Edwards <pedwards at disaster dot jaj dot com>]

Neither clause 21 nor 27 mentions anything special about NUL characters
showing up inside a std::string, and what happens when they do.  I think
the intention is to allow/support it, and that's good, but then we get
problems like PR libstdc++/2830.

1)  If we use the current implementation, we forward the formatted string
inserter to the formatted char* inserter:

    return __out << __s.c_str();             // current CVS
    return __out << __s.data();              // same results

The problem, of course, is that the formatted char* inserter calls length()
on the character sequence, which halts at the first NUL.


2)  If we instead forward the formatted string inserter to the *un*formatted
char* inserter, like this:

    return __out.write(__s.data(), __s.size());

and thus explicitly list the size, then PR 2830 and similar things work.  (I
have a version of the 2830 test added to 21_strings/inserters_extractors.cc
in my local tree, and will check it in along with whatever fix we decide on.)

However, 27_io/ostream_inserter_char:test02 then fails, because the
unformatted char* inserter isn't doing padding.  The formatted string
inserter requires padding, so we would have to do some checking before
forwarding.


So, first question:  if a std::string contains a NUL, should formatted I/O
work?  Or is that a "my arm hurts when I do this / then don't do that" case?

If the answer is yes it should work, then we have a bug, and the second
question is:  what next?


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.