This is the mail archive of the
mailing list for the GCC project.
Re: [v3] Fix stringbuf handling of NUL characters
At 04:15 PM 12/07/2001 -0400, Phil Edwards wrote:
>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.
According to your original analysis, strlen() wasn't involved in the
operation since a) string::size() doesn't use it (the length is stored
internally); and b) strlen() isn't invoked by the constructor if the length
is explicitly supplied.
Maybe we're talking about different things here. I was referring only to
the context of the copy-constructor patch which you included in your email,
not the general situation of what happens with c_str() when there are NULs
in the string.
- Andrew Snare