Argh. This is unfortunate. It's always pained me that the signed-ness ofchar was left undefined.

This is a little painful, as I have often usedbasic_string as a container for binary data. I have a lot of code in a lot of projects that will need to be updated!

The methods for find and replace in the string class are often useful for binary data as well. That probably isn't too helpful for a field or two in the option classes in this library, but I will consider the best thing to do. Using avector is fine for this specific case, but I wonder if it would be useful to just define achar_traits<unsigned char>.

Using a vector is fine for this specific case, but I wonder if it would be useful to just define achar_traits<unsigned char>.

This woulddefinitely break user code, I think, and even if it wouldn't it would certainly break the standard library's API.

I'm not a language lawyer but as far as I know a user-defined specializationstd::char_traits<unsigned char> is undefined behavior since it's an explicit specialization of a template defined in namespace std for a type that's not user-defined. You have to use a custom character type likestruct MyChar { unsigned char c_; } if you want to use the benefits of the basic_string template for binary data. See the (rather old) requestn1985 for a discussion of the details involved andhttps://reviews.llvm.org/D138307 for why it is removed from libc++.

Hey. Apologies that I'm slammed at work and haven't had much time to jump on this.

I also want to make it clear that the proposed PR, and any number of other solutions would be perfectly adequate to fix the ALPN field inssl_options. I'm just thinking out loud because I have consistently, and successfully, usedbasic_string<unsigned char> as a binary contained in any number of other proprietary and open-source projects. And would like to continue to do so.

First, it always seemed idiotic to me that C++ hassigned char. And thatchar is platform specific. Seriously? I know it was done for performance reasons around computers from the 1970's, but that was 50 years ago!

And now,unsigned char is a valid, standard, C++ character type, but is not supported in the primary character collection?!?!

Ugh.

After looking at a few things, I agree that actuallydefiningstd::char_traits<unsigned char> in a library could be problematic. But you you need to? Or can you just define something that conforms to it? The std one is just the default in thebasic_string template:

template<    class CharT,    class Traits = std::char_traits<CharT>,    class Allocator = std::allocator<CharT>> class basic_string;

Couldn't I just define amy_uchar_traits and use that?

using binary_blob = std::basic_string<unsigned char, my_uchar_traits>;

@fpagliughi

Couldn't I just define a my_uchar_traits and use that?

using binary_blob = std::basic_string<unsigned char, my_uchar_traits>;

You absolutely can, and it's a reasonable thing to do.

I agree, that would work. There is even more wonky stuff written about this topic inp0551r3.pdf, where it says that for a template specialization in namespace std to be fine it needs to have at least one template parameter depend on a user-defined type.

The libc++ authors argue that they can't provide a base implementation of template char_traits because there is none that would work for all parameters. That makes sense but I still don't see a good reason to remove the explicit specialization for unsigned char. I think they could have offered it as a vendor extension, even in light of the above-mentioned paper.

This is now a pressing matter as Apple recently updated XCode and the new release has a clang and libc++ version that barfs on this issue.