RE: [RFC PATCH 2/4] tools/nolibc: add integer types and integer limit macros

From: David Laight
Date: Mon Feb 20 2023 - 04:14:15 EST


From: Willy Tarreau
> Sent: 19 February 2023 18:52
>
> This commit adds some of the missing integer types to stdint.h and adds
> limit macros (e.g. INTN_{MIN,MAX}).
>
...
>
> +typedef int8_t int_least8_t;
> +typedef uint8_t uint_least8_t;
> +typedef int16_t int_least16_t;
> +typedef uint16_t uint_least16_t;
> +typedef int32_t int_least32_t;
> +typedef uint32_t uint_least32_t;
> +typedef int64_t int_least64_t;
> +typedef uint64_t uint_least64_t;

The are also the 'fast' variants.
Although I'd be tempted to either not define the 'least'
or 'fast' types (or maybe define them all as 'long').
The only code I've ever seen that used uint_fast32_t
got 'confused' when it was 64 bits.

...
> +/* limits of integral types */
> +
> +#define INT8_MIN (-128)
> +#define INT16_MIN (-32767-1)
> +#define INT32_MIN (-2147483647-1)
> +#define INT64_MIN (-9223372036854775807LL-1)

Those big decimal numbers are difficult to check!
A typo would be unfortunate!
Maybe (eg):
#define INT64_MIN (-INT64_MAX - 1)

> +#define INT8_MAX (127)
> +#define INT16_MAX (32767)
> +#define INT32_MAX (2147483647)
> +#define INT64_MAX (9223372036854775807LL)
> +
> +#define UINT8_MAX (255)
> +#define UINT16_MAX (65535)
> +#define UINT32_MAX (4294967295U)
> +#define UINT64_MAX (18446744073709551615ULL)

None of those need brackets.
Defining in hex would be more readable.
Although all the 'f' get hard to count as well.
Given that the types are defined in the same file, why
not use ~0u and ~0ull for UINT32_MAX and UINT64_MAX.

Should UINT8_MAX and UINT16_MAX be unsigned constants?
(Or even be cast to the corresponding type?)
It doesn't affect arithmetic, but would make a difference
to the over-zealous type checking in the kernel min/max
defines.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)