On March 9, 2025 8:48:26 AM PDT, Kuan-Wei Chiu <visitorckw@xxxxxxxxx> wrote: >On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote: >> On March 7, 2025 11:53:10 AM PST, David Laight <david.laight.linux@xxxxxxxxx> wrote: >> >On Fri, 07 Mar 2025 11:30:35 -0800 >> >"H. Peter Anvin" <hpa@xxxxxxxxx> wrote: >> > >> >> On March 7, 2025 10:49:56 AM PST, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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? > >Thanks for all the suggestions. > >I don't have a strong opinion on the naming or return type. I'm still a >bit confused about whether I can assume that casting bool to int always >results in 0 or 1. > >If that's the case, since most people prefer bool over int as the >return type and some are against introducing u1, my current plan is to >use the following in the next version: > >bool parity_odd(u64 val); > >This keeps the bool return type, renames the function for better >clarity, and avoids extra maintenance burden by having just one >function. > >If I can't assume that casting bool to int always results in 0 or 1, >would it be acceptable to keep the return type as int? > >Would this work for everyone? > >Regards, >Kuan-Wei You *CAN* safely assume that bool is an integer type which always has the value 0 or 1.
