This is the mail archive of the
mailing list for the libstdc++ project.
Re: [v3] Fix stringbuf handling of NUL characters
- To: Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Subject: Re: [v3] Fix stringbuf handling of NUL characters
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Thu, 12 Jul 2001 16:15:04 -0400
- Cc: Andrew Snare <ASnare at allshare dot nl>, libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Mathew Pitchforth <mathew at pandromeda dot com>
- References: <email@example.com> <firstname.lastname@example.org>
On Thu, Jul 12, 2001 at 10:32:15AM +0200, Gabriel Dos Reis wrote:
> Andrew Snare <ASnare@allshare.nl> writes:
> | Just looking at this patch at face value, I would have thought that
> | __str.data() would be better to use in this situation. Without referring
> | to the exact wording of the standard, I would argue that the results of
> | c_str() are undefined if the string contains NUL characters -- it does,
> | after all, return a C-style string which is NUL-terminated (and thus
> | one could argue nothing after that NUL is valid). On the other hand,
> | data() specifically returns the string data as-is, and doesn't bother
> | to NUL-terminate it.
Since we're talking about NUL characters in the middle of the data,
I would argue that it's a meaningless distinction. Whether the data is
NUL-terminated or not won't matter, since strlen() only reads to the first
NUL, not the second/third/Nth NUL which terminates the data.
However, this is a good change to make for another reason: our
implementation of data() is faster than our implementation of c_str(),
and since we're specifying the size, the NUL terminator doesn't need to
be there. :-)
Would I had phrases that are not known, utterances that are strange, in
new language that has not been used, free from repetition, not an utterance
which has grown stale, which men of old have spoken.
- anonymous Egyptian scribe, c.1700 BC