netdev - Re: [PATCH RFC net-next 3/3] netfilter: uapi: Use UAPI definition of INT_MAX and INT

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: <20260112090140-8b5fb693-989f-4af6-b65c-9c24a12d8779@linutronix.de>
Date: Mon, 12 Jan 2026 09:06:27 +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 Fri, Jan 09, 2026 at 11:20:22AM +0100, Thomas Weißschuh wrote:
> 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:

(...)

> > 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.

It turns out that the compiler only provides __INT_MAX__, not __INT_MIN__.
We can derive INT_MIN from INT_MAX as done in the original commit, but
open-coding it is ugly as heck. So we are back to a definition in a header
file again.

What about putting them in uapi/linux/types.h or adding a new
uapi/linux/typelimits.h?


Thomas