On Tue, Jun 13, 2023 at 03:10:48PM +0000, Joseph Myers wrote:
> > So why does C2X say
> > Recommended practice
> > It is recommended to produce a diagnostic message if type2 or type3 are
> > not suitable integer types, or if *result is not a modifiable lvalue of
> > a suitable integer type.
> > ?
> > Or is it meant that a suitable integer type doesn't need to be necessarily
> > one that is listed in the previous paragraph?
> > Perhaps the checking could be guarded on #ifdef __STRICT_ANSI__, sure...
>
> Diagnostics are better than doing something completely random - but making
> it conditional when there are sensible semantics also makes sense.
>
> It seems likely a future standard version will support these operations
> for bit-precise types, at least. (Bit-precise types are generally tricky
> for type-generic operations; there's no standard way to select on them
> with _Generic beyond listing individual types with specific widths, and no
> standard way to determine the width of the bit-precise type of an
> argument. So implementing some type-generic operations for such types may
> need new language extensions, prompting WG14 caution about requiring such
> support - but this also makes support for such types in standard
> type-generic macros in headers particularly valuable, precisely because
> they can't be implemented purely in user code using standard language
> features.)
Yeah, having say __builtin_{clz,ctz,ffs,popcount,parity} variants which would
be typegeneric and would allow say any normal integral or _BitInt type
(or just unsigned versions thereof?) would be useful. Even without _BitInt
we have the problem that we don't have builtins for __uint128_t.
One question is if we should keep them UB on zero input or hardcode some
particular
behavior for clz/ctz. The backend defaults might not be appropriate, I
think if we'd make it non-UB, using the precision of the type would be
reasonable, whatever it is (__builtin_clzb ((unsigned _BitInt(126)) 0)
might be 126 etc.).
Jakub
