Will C++11 std::string::operator[] return null-terminated buffer

Question

I have an object of the std::string class that I need to pass to C function that operates the char* buffer by iterating over it and searching for the null terminated symbol.

So, I have something like this:

// C function
void foo(char* buf);

// C++ code
std::string str("str");
foo(&str[0]);

Suppose that we use C++11, so we have a guarantee that std::string representation will have contiguously stored characters.

But I wonder is there any guarantee that &str[0] will point to the buffer that ends with \0? Yeah, there's c_str member function but I'm talking about operator[].

Can somebody quote the standard please?

@Mohit Jain Because that function accepts `char*`, not `const char*` — FrozenHeart, Aug 10 '16 at 12:59
Related: http://stackoverflow.com/questions/7554039/is-stringc-str-no-longer-null-terminated-in-c11 — Mohit Jain, Aug 10 '16 at 13:01
@FrozenHeart I am not 100% but I think that modifying the buffer of a `std::string` is probably UB (see the *Requires* in @Zereges answer). — Holt, Aug 10 '16 at 13:11
@Holt But foo doesn't mofidy the existing buffer, it just iterates over it — FrozenHeart, Aug 10 '16 at 13:13
@FrozenHeart Then why do you need a `char*` instead of a `const char*`? — Holt, Aug 10 '16 at 13:14

score 7 · Accepted Answer · answered Aug 10 '16 at 13:27

In practice, yes. There are exactly zero implementations of std::string that are standards-comforming that do not store a NUL character at the end of the buffer.

So if you aren't wondering for wondering sake, you are done.

However, if you are wondering about the standard being abtruse:

In C++14, yes. There is a clear requirement that [] return a contiguous set of elements, and [size()] must return a NUL character, and const methods may not modify state. So *((&str[0])+size()) must be the same as str[size()], and str[size()] must be a NUL, thus game over.

In C++11, almost certainly. There are rules that const methods may not modify state. There are guarantees that data() and c_str() return a null-terminated buffer that agrees with [] at each point.

A convoluted reading of C++11 standard would state that prior to any call of data() or c_str(), [size()] doesn't return the NUL terminator at the end of the buffer but rather a static const CharT that is stored separately, and the buffer has an unitialized (or even a trap value) where NUL should be. Due to the requirement that const methods not modify state I believe this reading is incorrect.

This requires &str[str.size()] change between calls to .data(), which is an observable change in state in string over a const call, which I would read as being illegal.

An alternative way to get around the standard might be to not initialize str[str.size()] until you legally access it via calling .data(), .c_str() or actually passing str.size() to operator[]. As there are no defined ways to access that element other than those 3 in the standard, you could stretch things and say lazy initialization of the NUL is legal.

I'd question this, as the definition of .data() implies that the return value of [] is contiguous, so &[0] is the same address as .data(), and .data()+.size() is guaranteed to point to a NUL CharT so must (&[0])+.size(), and with no non-const methods called the state of the std::string may not change between the calls.

But, what if the fact the compiler can look and see you'll never call .data() or .c_str(), does the requirement of contiguity hold if it can be proven you never call them?

At which point I'd throw my hands up and shoot the hostile compiler.

The standard is very passively voiced about this. So there may be a way to make an arguably standards conforming std::string that doesn't follow these rules. And because the guarantees get closer and closer to explicitly requiring that NUL terminator there, the odds against a new compiler showing up that uses a tortured reading of C++ to claim this is standards compliant is low.

I think this falls into Occam's Implementation: The simplest implementation is the most likely until proven otherwise. — Mgetz, Aug 10 '16 at 13:29
@Mgetz True, but we also want to ensure that no pathological compiler comes along and says "that is UB, so I'll optimize around it not happening". *cough* gcc *cough* something in my throat. — Yakk - Adam Nevraumont, Aug 10 '16 at 13:32
*At which point I'd throw my hands up and shoot the hostile compiler.* Also cremate it and scatter the ashes so it cannot bother anyone ever again. — NathanOliver, Aug 10 '16 at 13:36
"There is a clear requirement that [] return a contiguous set of elements, and [size()] must return a NUL character" -- could you quote it? In fact, I don't see any differences between `operator[]` descriptions in C++11 and C++14 drafts — FrozenHeart, Aug 10 '16 at 14:13

Zereges · Answer 2 · 2016-08-10T20:40:14.753

5

According to standard, yes. Underlying char container is accessible using string::data or string::c_str on which standard says:

21.4.7.1 basic_string accessors [string.accessors]
const charT* c_str() const noexcept;
const charT* data() const noexcept;

1 Returns: A pointer p such that p + i == &operator[](i) for each i in [0,size()].
2 Complexity: Constant time.
3 Requires: The program shall not alter any of the values stored in the character array.

And to prove, that it's null-terminated, look at definition of operator[] (emphasis mine):

21.4.5 basic_string element access [string.access]
const_reference operator[](size_type pos) const;
reference operator[](size_type pos);

1 Requires: pos <= size().
2 Returns: *(begin() + pos) if pos < size(). Otherwise, returns a reference to an object of type charT with value charT(), where modifying the object leads to undefined behavior.
3 Throws: Nothing.
4 Complexity: Constant time.

thus operator[size()] returns charT() and since std::string is std::basic_string<char>, charT() is '\0'.

That means, in your case, *(&str[0] + str.size()) == '\0' shall be, according to standard, always true.

Beware, that modifying operator[size()] is UB.

edited Aug 10 '16 at 20:40

answered Aug 10 '16 at 13:07

Zereges

5,139
1
25
49

1

Where does it state that it should be null-terminated? – FrozenHeart Aug 10 '16 at 13:09
Exactly. I was searching for this. I had read this long back. – Nawaz Aug 10 '16 at 13:09
Does point 3 mean that you *shouldn't* use this to pass that pointer to function accepting `char*`? – el.pescado - нет войне Aug 10 '16 at 13:10
@FrozenHeart: Think logically and step by step: 1) `c_str()` has to be null-terminated (it is mentioned elsewhere in the spec) .... 2) and `p+i == &operator[](i)` is valid for all `i` in the range `[0, size()]` which means the address of last character when `i==size()` is `\0`. – Nawaz Aug 10 '16 at 13:11
@el.pescado exactly, if you need to pass a string that might be modified I suggest copying it (including the 0 terminator) to a vector 1st. – Richard Critten Aug 10 '16 at 13:12
@el.pescado But `foo` doesn't mofidy the existing buffer, it just iterates over it – FrozenHeart Aug 10 '16 at 13:13
1

@FrozenHeart perhaps foo should be `void foo(char const * buf);` then – Richard Critten Aug 10 '16 at 13:15
@Richard Critten Well, I can't modify that function – FrozenHeart Aug 10 '16 at 13:17
This describes the effect of calling `data()` and `c_str()`. The OP asked about `(&str[0])+str.size()` which does not involve calling `data()` or `c_str()`. A connection may be made, but it is not free. – Yakk - Adam Nevraumont Aug 10 '16 at 13:20
@FrozenHeart by the way, do you want "practically"? Practically this is absolutely safe, there are no compliant `std::string` implementations without the property you ask for. What is going on is the fact that the standard is *extremely abtruse* in this section about it. – Yakk - Adam Nevraumont Aug 10 '16 at 13:21
@Nawaz I said it wasn't free, not that it cannot be made. – Yakk - Adam Nevraumont Aug 10 '16 at 13:28

Will C++11 std::string::operator[] return null-terminated buffer

2 Answers2