[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae78ddb2-7b5f-4d3b-adef-97b0ab363a30@lunn.ch>
Date: Mon, 5 Jan 2026 15:37:14 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>,
Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>, Phil Sutter <phil@....cc>,
Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
coreteam@...filter.org
Subject: Re: [PATCH RFC net-next 1/3] uapi: add INT_MAX and INT_MIN constants
On Mon, Jan 05, 2026 at 09:26:47AM +0100, Thomas Weißschuh wrote:
> Some UAPI headers use INT_MAX and INT_MIN. Currently they include
> <limits.h> for their definitions, which introduces a problematic
> dependency on libc.
>
> Add custom, namespaced definitions of INT_MAX and INT_MIN using the
> same values as the regular kernel code.
Maybe a dumb question.
> +#define __KERNEL_INT_MAX ((int)(~0U >> 1))
> +#define __KERNEL_INT_MIN (-__KERNEL_INT_MAX - 1)
How does this work for a 32 bit userspace on top of a 64 bit kernel?
And do we need to be careful with KERNEL in the name, in that for a 32
bit userspace, this is going to be 32bit max int, when in fact the
kernel is using 64 bit max int?
Andrew
Powered by blists - more mailing lists