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

[Arnd Bergmann]

On Mon, Jan 12, 2026, at 09:06, Thomas Weißschuh wrote:
> 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:
>> > 
>> > - 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.

Indeed, even gcc's own limits.h does the derivation of each
signed type's limits like

#undef INT_MIN
#define INT_MIN (-INT_MAX - 1)
#undef INT_MAX
#define INT_MAX __INT_MAX__

so it's clearly safe, but open-coding is not very clear.

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

Those both seem fine to me. Or possibly a netfilter-specific
macro in uapi/linux/netfilter.h, as all three headers that
actually need INT_MIN are all netfilter specific and include
that header already.

      Arnd