Re: NUL chars in formatted and unformatted string I/O

[Nathan Myers <ncm at nospam dot cantrip dot org>]

On Fri, May 18, 2001 at 03:00:32AM -0400, Phil Edwards wrote:
> 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.

I agree that Mr. Simpson has reported a grave bug.  Are there other
similar examples of intolerance of embedded NULs?
 
> 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.
 
This is seriously broken.   Throughout the library, where one function
calls another, it should always be the other way: call the content-
insensitive form, and get the length from the struct, counting only 
where there is no other meaningful choice.
 
> 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.)

Please check it in now.  Tests that reveal current bugs are the most
valuable.  
 
> 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?

Of course formatted I/O should work properly.  NUL is just another 
control character.  C++ is supposed to fix the idiocies of its C legacy 
where it can, not propagate them.
 
> If the answer is yes it should work, then we have a bug, and the second
> question is:  what next?

bits/basic_string.h has lots of examples of correct forwarding.

Nathan Myers
ncm at cantrip dot org