This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]