[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260109111310-4b387d2e-1459-4701-9e58-dc02ad74c499@linutronix.de>
Date: Fri, 9 Jan 2026 11:20:21 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Arnd Bergmann <arnd@...db.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>, Andrew Lunn <andrew@...n.ch>,
Pablo Neira Ayuso <pablo@...filter.org>, Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>, Phil Sutter <phil@....cc>, linux-kernel@...r.kernel.org,
Netdev <netdev@...r.kernel.org>, netfilter-devel@...r.kernel.org, coreteam@...filter.org
Subject: Re: [PATCH RFC net-next 3/3] netfilter: uapi: Use UAPI definition of
INT_MAX and INT_MIN
On Mon, Jan 05, 2026 at 02:02:17PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 5, 2026, at 09:26, Thomas Weißschuh wrote:
> > Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
> > dependency on a libc, which UAPI headers should not do.
> >
> > Use the equivalent UAPI constants.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
>
> I agree with the idea of the patch series, but I think this
> introduces a different problem:
>
> > #include <linux/in.h>
> > +#include <linux/limits.h>
>
> linux/limits.h is not always clean against limits.h. In glibc,
> you can include both in any order, but in musl, you cannot:
>
> gcc -xc /dev/null -nostdinc -I /usr/include/aarch64-linux-musl -include limits.h -include linux/limits.h -o - -Wall -c
> In file included from <command-line>:
> /usr/include/aarch64-linux-musl/linux/limits.h:7: warning: "NGROUPS_MAX" redefined
> 7 | #define NGROUPS_MAX 65536 /* supplemental group IDs are available */
> |
> In file included from <command-line>:
> /usr/include/aarch64-linux-musl/limits.h:48: note: this is the location of the previous definition
> 48 | #define NGROUPS_MAX 32
Ack.
> I can think of two alternative approaches here:
>
> - put the __KERNEL_INT_MIN into a different header -- either a new one
> or maybe uapi/linux/types.h
> - use the compiler's built-in __INT_MIN__ instead of INT_MIN in
> UAPI headers.
If we can rely on compiler built-ins I would prefer this option.
> On the other hand, there are a few other uapi headers
> that already include linux/limits.h:
>
> include/uapi/linux/auto_fs.h:#include <linux/limits.h>
> include/uapi/linux/fs.h:#include <linux/limits.h>
> include/uapi/linux/netfilter/xt_bpf.h:#include <linux/limits.h>
> include/uapi/linux/netfilter/xt_cgroup.h:#include <linux/limits.h>
> include/uapi/linux/netfilter/xt_hashlimit.h:#include <linux/limits.h>
...
Thomas
Powered by blists - more mailing lists