Paul Eggert wrote: > > if the memcpy examples used exact-width types for "value", then > > the code would compile if CHAR_BIT == 8 && sizeof(uint_least16_t) == 2, > > and otherwise fail to compile. The return type can still be a _leastN_t. > > Thanks for pointing out the problem. Of course the issue is mostly > theoretical, but an even better fix is to change the code so that it > compiles and runs correctly even on platforms that lack exact-width > types like uint16_t. Done via the attached patch.
Thanks. That looks good. But this use of uint_leastN_t is probably worth a comment: 2026-03-16 Bruno Haible <[email protected]> stdc_memrevers8u: Add comment. * lib/stdbit.in.h (stdc_memreverse8u*): Add comment regarding uint_leastN_t. diff --git a/lib/stdbit.in.h b/lib/stdbit.in.h index 10e311ec72..8b61300041 100644 --- a/lib/stdbit.in.h +++ b/lib/stdbit.in.h @@ -1332,6 +1332,11 @@ stdc_memreverse8 (size_t n, unsigned char *ptr) #if @GNULIB_STDC_MEMREVERSE8U@ +/* Note: ISO C defines these functions with argument and return type uintN_t. + We do it here with argument and return type uint_leastN_t. This is a + generalization that does not contradict ISO C: When uintN_t exists, it is + known that uint_leastN_t is the same type as uintN_t. */ + _GL_STDC_MEMREVERSE8U_INLINE uint_least8_t stdc_memreverse8u8 (uint_least8_t value) {
