3 ms·
> std::string::c_str returns the same address as &string[0] Note that this by itself doesn't imply null-termination, though as you say strings are indeed null-
by dataflow 2y ago
> std::string::c_str returns the same address as &string[0]
Note that this by itself doesn't imply null-termination, though as you say strings are indeed null-terminated now.
Edit: This is not particularly obvious, but the reason this has nothing to do with allocation or the return value is that the implementation could still leave space for the null terminator, but avoid actually setting it to zero until c_str() is invoked. That would neither affect the returned pointer nor the constant-time guarantee.
- masspro 2y agoWhy downvotes? Ignoring C++11 changes for a minute, c_str is absolutely able to cause a reallocation if it needs to, such that after it returns, its return value and the value of data() are the same. Ergo no, the GP statement alone doesn’t imply anything.
- dietr1ch 2y agoShouldn't c_str() be null terminated? Then if it must point to the actual backing store, then that must also be a valid null terminated C string as there's no other way to use them.
- dataflow 2y ago> Shouldn't c_str() be null terminated? Yes, by definition. > Then if it must point to the actual backing store, then that must also be a valid null terminated C string as there's no other way to use them. No, this doesn't follow. The buffer could leave room for the terminator but not actually write the terminator until c_str() is called. That's why the C++11 standard had to explicitly require that the string always be null-terminated regardless of whether c_str() is called.
- dietr1ch 2y agoWow, I didn't expect `c_str()` to write at all. I knew that C++ was wild before C++57, but before C++ is insane. Thanks for the explanation!
- jcelerier 2y agoI don't think any implementation ever did this. But it was "technically possible" as the spec didn't prevent it so you have to account for it.