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

[AlexGuteniev]

_Char is directly compared against _Elem0 and _Elem1

STL/stl/inc/bitset

Lines 589 to 600 in 73b5791

	if (_Tr::eq_int_type(_Tr::eof(), _Meta)) { // end of file, quit
	_State |= _Istr_t::eofbit;
	break;
	} else if ((_Char = _Tr::to_char_type(_Meta)) != _Elem0 && _Char != _Elem1) {
	break; // invalid element
	} else if (_Str.max_size() <= _Str.size()) { // no room in string, give up (unlikely)
	_State |= _Istr_t::failbit;
	break;
	} else { // valid, append '0' or '1'
	_Str.push_back('0' + (_Char == _Elem1));
	_Changed = true;
	}

[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):

STL/stl/inc/bitset

Line 121 in a26f4ad

if (!_Traits::eq(_Elem1, _Ch) && !_Traits::eq(_Elem0, _Ch)) {

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?