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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4da90248dbe94c5db1036cd873dfd910@AcuMS.aculab.com>
Date:   Mon, 20 Feb 2023 09:14:04 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Willy Tarreau' <w@....eu>, Vincent Dagonneau <v@....io>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 2/4] tools/nolibc: add integer types and integer limit
 macros

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)