[PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

[H. Peter Anvin]

On March 7, 2025 11:53:10 AM PST, David Laight <david.laight.linux at gmail.com> wrote:
>On Fri, 07 Mar 2025 11:30:35 -0800
>"H. Peter Anvin" <hpa at zytor.com> wrote:
>
>> On March 7, 2025 10:49:56 AM PST, Andrew Cooper <andrew.cooper3 at citrix.com> wrote:
>> >> (int)true most definitely is guaranteed to be 1.  
>> >
>> >That's not technically correct any more.
>> >
>> >GCC has introduced hardened bools that intentionally have bit patterns
>> >other than 0 and 1.
>> >
>> >https://gcc.gnu.org/gcc-14/changes.html
>> >
>> >~Andrew  
>> 
>> Bit patterns in memory maybe (not that I can see the Linux kernel using them) but
>> for compiler-generated conversations that's still a given, or the manager isn't C
>> or anything even remotely like it.
>> 
>
>The whole idea of 'bool' is pretty much broken by design.
>The underlying problem is that values other than 'true' and 'false' can
>always get into 'bool' variables.
>
>Once that has happened it is all fubar.
>
>Trying to sanitise a value with (say):
>int f(bool v)
>{
>	return (int)v & 1;
>}    
>just doesn't work (see https://www.godbolt.org/z/MEndP3q9j)
>
>I really don't see how using (say) 0xaa and 0x55 helps.
>What happens if the value is wrong? a trap or exception?, good luck recovering
>from that.
>
>	David

Did you just discover GIGO?