I don't think std::string should be a problem in this case, if you want to construct a buffer from an std::string, you wouldn't be using this overload anyway, since it's a pointer to a char, not an array of characters. It would only be a problem for someone who has a proper array of chars that is not null-terminated. This is not exactly unimaginable, but it's certainly unlikely and nothing is preventing anyone from using unsigned char here. On wo, 2017-11-29 at 07:47 +0100, Richard Hodges via Boost-users wrote:
On 29 November 2017 at 02:58, Gavin Lambert via Boost-users
wrote: On 29/11/2017 01:57, Richard Hodges wrote:
It gives me the shivers. Binary data could easily have a zero in the last byte.
In theory those should be distinguishable -- char is a distinct type from unsigned char (even if char is unsigned by default), and *hopefully* anyone poking binary data at the wire is doing so as an unsigned char or uint8_t. In reality, in my world (e.g. protocol buffers), std::string is a more useful type for binary data buffers that std::vectorstd::uint8_t. I know it's a different type, but still, it's chars modelling bytes. This is not an uncommon idea.
The fact that you can't construct a std::vector from data without a copy means that std::vector<byte> is less suitable for buffering data than one might imagine.
In practice, there might be some trouble with people abusing std::string as if it were std::vector
by pointer casting. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users