`<bitset>`: streaming `operator >>` does not use character traits

[AlexGuteniev]

_Char is directly compared against _Elem0 and _Elem1 https://github.com/microsoft/STL/blob/73b5791e5c9eff1ece3ce593571fb30c31bf08d9/stl/inc/bitset#L589-L600

[AlexGuteniev]

If we want test coverage, we could wait for #4951 and then share significant test part.

[StephanTLavavej]

We checked, and fortunately bitset's constructor properly implements WG21-N4988 [bitset.cons]/6 "The function uses traits::eq to compare the character values." (here and on other lines):

https://github.com/microsoft/STL/blob/a26f4adb1ecf767784bb4e4318093c4579fdb364/stl/inc/bitset#L121

So the problem is limited to the streaming operator. We'll grumble a bit that [bitset.operators]/5.3 "the next input character is neither is.widen('0') nor is.widen('1') (in which case the input character is not extracted)" is vague about how "neither" is determined, and this probably deserves an LWG issue, but the intent seems to be clear enough.

[AlexGuteniev]

Apparently it looks complicated to write a test. In addition to char_traits have either to specialize ctype or to define _ENFORCE_FACET_SPECIALIZATIONS to zero.

• Specializing ctype looks too much effort for this issue
• Disabling _ENFORCE_FACET_SPECIALIZATIONS doesn't look right, as it would be using a nonstandard mode for a pedantic bug.

[CaseyCarter]

Apparently it looks complicated to write a test. In addition to char_traits have either to specialize ctype

You have to specialize ctype if you define a custom character type, but can you avoid it if you define your own traits class for char instead?