[clang:frontend] Feature request: warn when converting `bool` to a character type (P3765R0)

[eisenwave]

Hey, I recently presented cplusplus/papers#2384 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3765r0.html) in Kona 2025 during the WG21 meeting.

The goal of the paper was to introduce a deprecation for the implicit conversion in cases like:

std::string_view str = /* ... */;
if (str.ends_with('\n' || str.ends_with('\r'))) {
    // ...
}

This is an extremely evil bug: it's equivalent to checking whether str ends with U+0001 START OF HEADING (assuming ASCII char). See the paper for more discussion. In the ASCII/Unicode interpretation:

• false is converted to U+0000 NULL
• true is converted to U+0001 START OF HEADING

The committee wasn't open to having this in the standard, but it seemed like implementers were interested in adding a compiler warning that is enabled by default here. The conversions from bool to char is semantically quite nonsensical (unless char is abused a general integer type), and leads to bugs such as the one shown in the example.

[eisenwave]

There is an existing commit by @hanickadot at d7b8025 which implements most of the change; there are no tests yet though.

[shafik]

CC @cor3ntin @AaronBallman

[shafik]

Are there any clang-tidy checks that catch this?

[eisenwave]

Yes, https://clang.llvm.org/extra/clang-tidy/checks/readability/implicit-bool-conversion.html catches this, but it's a much more aggressive superset. Plenty of code contains an implicit conversion from bool to e.g. int in branchless arithmetic, like:

'a' + (x > 0); // promotions char->int, bool->int

bool-to-char is more obscure and might realistically be a default compiler warning.

[AaronBallman]

I'm concerned about the false-positive rate for this.

It's not uncommon for there to be custom boolean types which are a typedef to a character type: https://sourcegraph.com/search?q=context:global+-file:.*test.*+%22typedef+unsigned+char+boolean%3B%22&patternType=keyword&case=yes&sm=0 (there's less if you limit to just C++ but it still exists).

What's more, you have to worry about this kind of situation:

struct S {
  uint8_t b : 1;
} s = { true };

But I think we can probably find good heuristics to reduce the false positives to a more reasonable rate.

[eisenwave]

It's not uncommon for there to be custom boolean types which are a typedef to a character type: https://sourcegraph.com/search?q=context:global+-file:.*test.*+%22typedef+unsigned+char+boolean%3B%22&patternType=keyword&case=yes&sm=0 (there's less if you limit to just C++ but it still exists).

You are searching for unsigned char, which is not a character type. I do not propose deprecating anything related to signed char or unsigned char. This would indeed raise quite a lot of false positives for ordinary numeric code using int8_t and uint8_t.

What's more, you have to worry about this kind of situation:

Once again, this example uses uint8_t, which a conforming implementation cannot define as char, even if char has an unsigned underlying type.

The proposed warning is only intended to target char (and other character types); conversion from bool to something that's intended to store ASCII text data is exotic to say the least. Even when char is used as a byte type (which is sometimes done even though unsigned char and std::byte are much better for this), it doesn't make much sense to convert true to the 0x01 byte value implicitly, in, say, a network protocol or file format.

[AaronBallman]

You are searching for unsigned char, which is not a character type.

https://eel.is/c++draft/basic.types#basic.fundamental-7.sentence-2 and the wording from C:

The three types char, signed char, and unsigned char are collectively called the character types.

hence the confusion.

I do not propose deprecating anything related to signed char or unsigned char.

That's good to know, thank you for clarifying! If this is just about char specifically and not character types in general, I think it's a bit more palatable, but the same concerns remain: https://sourcegraph.com/search?q=context:global+-file:.*test.*+%22typedef+char+boolean%3B%22&patternType=keyword&case=yes&sm=0

(I didn't have the time to figure out the right regex to show use of char to define a bit-field, but they do happen in the wild as well.)

[eisenwave]

TIL C++ and C have different definitions of "character type".

Not really sure what to make of your search results. I don't get why anyone would be defining their own boolean type in C++, given there has always been a fundamental type for this. In C, it makes sense.

However, in C, the deprecation warning would be virtually impossible to trigger with what you've shown because people define false as 0 (int) and logical operators (&&, ||) produce int. _Bool basically doesn't exist prior to C23 unless you really go out of your way to use it. And if you go out of your way to use _Bool, then you're presumably not defining your own boolean, are you?

In any case, there's always the option to opt out of warnings. I concede that there are some highly exotic ways to use the type system, but most people presumably use char for characters and bytes, and bool for boolean values, and mixing these is a category error.

[AaronBallman]

TIL C++ and C have different definitions of "character type".

It's an exciting world we live in. :-D

Not really sure what to make of your search results. I don't get why anyone would be defining their own boolean type in C++, given there has always been a fundamental type for this. In C, it makes sense.

The situations I'm aware of all basically boil down to "this header file is used by C89 and C++98" and they're using typedefs for ABI reasons.

However, in C, the deprecation warning would be virtually impossible to trigger with what you've shown because people define false as 0 (int) and logical operators (&&, ||) produce int. _Bool basically doesn't exist prior to C23 unless you really go out of your way to use it. And if you go out of your way to use _Bool, then you're presumably not defining your own boolean, are you?

Yeah, my concern is actually for the C++ side. e.g.,

typedef char Boolean;
#ifndef __cplusplus
#define true ((Boolean)1)
#define false ((Boolean)0)
#endif

void some_func(Boolean some_param);

(with or without the casts). So they're still using true and false in code when calling some_func() and assuming that the implicit conversions make everything okay in C++.

In any case, there's always the option to opt out of warnings. I concede that there are some highly exotic ways to use the type system, but most people presumably use char for characters and bytes, and bool for boolean values, and mixing these is a category error.

There are ways to opt out of warnings, but our policy is for new diagnostics to be on-by-default and so a high false positive rate causes tension. That's not to say "we shouldn't do this request", it's only to say we need to keep false positive rates in mind if someone picks up the task.

[cor3ntin]

I think this would be worth exploring - as long as we limit to char and nothing else -

• It might be worth doing at the start of a cycle so that we have time to gather feedback without being disruptive.

Maybe we can only do it in C++ and not C.

If a sufficient number of folks do that in C++ we might be stuck - because of ABI, as @AaronBallman said