Hi Michael, On Wed, Oct 15, 2025 at 06:10:25PM +0200, Michael Matz wrote: > Hello, > > On Wed, 15 Oct 2025, Alejandro Colomar wrote: > > > > ... while this doesn't. So it's not equivalent, add an outer cast to > > > bool > > > to make it so, and then you'd get: > > > > > > $ ./a.out > > > 1 > > > 0 > > > 1 > > > 1 > > > > True. Which makes it even worse: > > > > 2 at least is a valid power response for bit_ceil(), just as 0 is also > > a valid response, if we consider wrapping arithmetics, but 1 is not. > > Huh? Arguably that zero is even a power of anything is the special case; > 1 is always a power.
0 is 2 mod 2.
This is similar to the bug in arc4random_uniform(3).
arc4random_uniform(0) should return a random number in the range
[0, 2^32), if it weren't ill designed.
$ man -w arc4random | xargs mansect BUGS | man /dev/stdin | cat;
arc4random(3) Library Functions Manual arc4random(3)
BUGS
An upper_bound of 0 doesn’t make sense in a call to arc4ran‐
dom_uniform(). Such a call will fail, and return 0. Be careful,
since that value is not less than upper_bound. In some cases,
such as accessing an array, using that value could result in unde‐
fined behavior.
Linux man‐pages 6.15‐133‐gb... 2025‐06‐28 arc4random(3)
> Either way, the specific semantics of a single badly
> written (or badly specified) try at bit magic
It's not a badly written try; I pasted the code from shadow utils:
<https://github.com/shadow-maint/shadow/blob/3ea6df885d42a5acab9f641416daa5b06972eefd/lib/bit.h#L29>
Expanding and replacing stuff as appropriate. It's a conforming
implementation of C23's stdc_bit_ceilul(3).
> doesn't really influence
> what is or isn't orthogonal language design. Maxof/Minof makes sense for
> bool and has an obvious and single sensible definition, so leaving it out
> is surprising. Surprises usually fire back in language definitions.
As long as the surprise is a compiler error, I don't expect it to be too
bad.
I'm still waiting for GCC to fix support for arrays of zero elements,
FWIW. That's a case where GCC is being painful unnecessarily.
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036>
How about this deal? I agree to add support for bool in _Maxof and
_Minof, in exchange of a promise to fix support for arrays of [0]. :)
That's removing two artificial exceptions, after all.
> > And as we're seeing, bool belongs in a third class of integer types, in
> > which it is the only member. It doesn't belong in the class of unsigned
> > integer types (which is BTW something under discussion in the
> > C Committee at the moment).
>
> If saturated types are ever included it won't be the only member of that
> class.
As Joseph said, saturated arithmetic should not be a property of types,
but of functions. If you want saturated arithmetic, you should call
add_saturated(a,b).
> Even absent that the loneliness of bool doesn't imply anything
> specific.
It implies that bool is not used in type-generic macros that perform
operations on integer types.
> > But within the boolean class of integers, it makes no sense to use a
> > generic operator to get the limits, as there's only one type: bool.
> > Thus, you just hardcode true and false.
>
> I can envision different bool types (of different sizes for instance),
> where everything is naturally defined. Maxof/Minof would then return the
> correctly typed variants of true and false. But even that imagination
> isn't necessary to see that Maxof/Minof should "obviously" be defined for
> bool.
When those boolean types are added, it could make sense to do this.
> > And I have yet to see a macro that would make sense for all three
> > classes of integer types (signed, unsigned, and boolean).
>
> Maxof and Minof :-)
Could you please conceive a use for them with today's C?
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
signature.asc
Description: PGP signature
