<locale>: std::ctype<char>::blank return true for all space-characters

[fsb4000]

Describe the bug
blank returns true for '\r', '\n' ... it just works as an alias for std::ctype::space

From https://en.cppreference.com/w/cpp/string/byte/isblank

In the default C locale, only space (0x20) and horizontal tab (0x09) are classified as blank characters.

Command-line test case

C:\Temp>type main.cpp
#include <iostream> 
#include <locale> 
#include <cctype>

using namespace std;

int main()
{ 
	cout << isblank('\n') << '\n';
	cout << use_facet<ctype<char>>(locale("C")).is(ctype<char>::blank,
		static_cast<unsigned char>('\n')) << '\n';
	cout << use_facet<ctype<char>>(locale::classic()).is(ctype<char>::blank,
		static_cast<unsigned char>('\n')) << '\n';
}

C:\Temp>cl /EHsc /W4 /WX main.cpp
cl /EHsc /W4 /WX main.cpp
Оптимизирующий компилятор Microsoft (R) C/C++ версии 19.27.29109 для x64
(C) Корпорация Майкрософт (Microsoft Corporation).  Все права защищены.

main.cpp
Microsoft (R) Incremental Linker Version 14.27.29109.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:main.exe
main.obj

C:\Temp>main.exe
0
1
1

Expected behavior
Should return 0 0 0

STL version
Microsoft Visual Studio Community 2019 Preview Version 16.7.0 Preview 6.0
Additional context
VSO-429255 / AB#429255 | DevCom-215436 DevCom-246252 DevCom-51443

[Agrael1]

I've investigated the issue, it'll require rework on ucrt side of things, also this may break binary compatibility since the comparison flags may change.

[Arzaghi]

I've investigated this issue and spent some time on it. I agree with Ilya Doroshenko (@Agrael1). I think it's impossible to fix it without touching the following enum. I guess it breaks the ABI (?).

STL/stl/inc/xlocale

Lines 2359 to 2380 in 03ab954

	// STRUCT ctype_base
	struct _CRTIMP2_PURE_IMPORT ctype_base : locale::facet { // base for ctype
	enum { // constants for character classifications
	alnum = _DI | _LO | _UP | _XA,
	alpha = _LO | _UP | _XA,
	cntrl = _BB,
	digit = _DI,
	graph = _DI | _LO | _PU | _UP | _XA,
	lower = _LO,
	print = _DI | _LO | _PU | _SP | _UP | _XA | _XD,
	punct = _PU,
	space = _CN | _SP,
	upper = _UP,
	xdigit = _XD,
	blank = _CN | _SP
	};
	using mask = short; // to match <ctype.h>
	__CLR_OR_THIS_CALL ctype_base(size_t _Refs = 0) : locale::facet(_Refs) {}
	__CLR_OR_THIS_CALL ~ctype_base() noexcept {}
	};

If changing the above enum does break the binary compatibility then I think it should be marked as vNext and if it doesn't break ABI, please let me know. I can continue my draft PR.

[Agrael1]

Yep, I asked for vNext, but somehow flag wasn't set, issue was passed to ucrt team

[CraigHutchinson]

I just experienced this issue std::isblank('\n', std::locale::classic()) == true which is very unexepected!

[CraigHutchinson]

I've investigated this issue and spent some time on it. I agree with Ilya Doroshenko (@Agrael1). I think it's impossible to fix it without touching the following enum. I guess it breaks the ABI (?).

STL/stl/inc/xlocale

Lines 2359 to 2380 in 03ab954

	// STRUCT ctype_base
	struct _CRTIMP2_PURE_IMPORT ctype_base : locale::facet { // base for ctype
	enum { // constants for character classifications
	alnum = _DI | _LO | _UP | _XA,
	alpha = _LO | _UP | _XA,
	cntrl = _BB,
	digit = _DI,
	graph = _DI | _LO | _PU | _UP | _XA,
	lower = _LO,
	print = _DI | _LO | _PU | _SP | _UP | _XA | _XD,
	punct = _PU,
	space = _CN | _SP,
	upper = _UP,
	xdigit = _XD,
	blank = _CN | _SP
	};
	using mask = short; // to match <ctype.h>
	__CLR_OR_THIS_CALL ctype_base(size_t _Refs = 0) : locale::facet(_Refs) {}
	__CLR_OR_THIS_CALL ~ctype_base() noexcept {}
	};

If changing the above enum does break the binary compatibility then I think it should be marked as vNext and if it doesn't break ABI, please let me know. I can continue my draft PR.

As space and blank are the same value changing that enum isn't an ABI break from my understanding? i.e. Existing ABI calls are to _CN | _SP so changing the blank in this enum won't affect existing afaik. If code is rebuilt there would be a change in behaviour for the better but not sure why this remains unfixed tbh.

[StephanTLavavej]

We are more daring about behavioral changes these days - I suspect that fixing this can be done in an ABI-compatible way. Because it touches locales it is definitely one of the scarier outstanding issues though.