mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Willy Tarreau' <w@1wt.eu>, Vincent Dagonneau <v@vda.io>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [RFC PATCH 2/4] tools/nolibc: add integer types and integer limit macros
Date: Mon, 20 Feb 2023 09:14:04 +0000	[thread overview]
Message-ID: <4da90248dbe94c5db1036cd873dfd910@AcuMS.aculab.com> (raw)
In-Reply-To: <20230219185133.14576-3-w@1wt.eu>

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)


  parent reply	other threads:[~2023-02-20  9:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-19 18:51 [RFC PATCH 0/4] tools/nolibc: add stdint and more integer types Willy Tarreau
2023-02-19 18:51 ` [RFC PATCH 1/4] tools/nolibc: add stdint.h Willy Tarreau
2023-02-19 18:51 ` [RFC PATCH 2/4] tools/nolibc: add integer types and integer limit macros Willy Tarreau
2023-02-19 19:16   ` Thomas Weißschuh
2023-02-19 19:23     ` Willy Tarreau
2023-02-20  9:14   ` David Laight [this message]
2023-02-20 14:47     ` Willy Tarreau
2023-02-20 20:27       ` Vincent Dagonneau
2023-02-19 18:51 ` [RFC PATCH 3/4] tools/nolibc: enlarge column width of tests Willy Tarreau
2023-02-19 18:51 ` [RFC PATCH 4/4] tools/nolibc: add tests for the integer limits in stdint.h Willy Tarreau
2023-02-19 19:04   ` Thomas Weißschuh
2023-02-19 19:15     ` Willy Tarreau
2023-02-20 20:29       ` Vincent Dagonneau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4da90248dbe94c5db1036cd873dfd910@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=v@vda.io \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome