From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [nft PATCH] Fix for warnings when compiling for 32bit arch
Date: Sun, 27 Sep 2026 21:33:37 +0200 [thread overview]
Message-ID: <arlvkVx3c6_TvrWU@chamomile> (raw)
In-Reply-To: <20260917173707.2080891-1-phil@nwl.cc>
Hi Phil,
On Thu, Sep 17, 2026 at 07:37:07PM +0200, Phil Sutter wrote:
> This eliminates several, probably harmless warnings when e.g. compiling
> with '-m32' for x86_64:
>
> - Printing code assumes NFT_MAX_EXPR_LEN_BITS is unsigned long, when on
> 32bit it is unsigned int - multiply by 1UL to force the implicit type
>
> - Pointers are unsigned long, casting to uint64_t yields a warning on
> 32bit due to the different size
>
> - Bison tokens of type 'val' are uint64_t, print their values using
> PRIu64 macro
>
> - On 32bit, UINT32_MAX is of type unsigned int - cast to off_t when
> comparing against state->indesc->line_offset to avoid different
> signedness warning
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> include/expression.h | 2 +-
> src/netlink_linearize.c | 4 ++--
> src/parser_bison.y | 2 +-
> src/scanner.l | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/expression.h b/include/expression.h
> index e6a05603552b5..b3ba4ad8d297e 100644
> --- a/include/expression.h
> +++ b/include/expression.h
> @@ -11,7 +11,7 @@
> #include <json.h>
> #include <libnftnl/udata.h>
>
> -#define NFT_MAX_EXPR_LEN_BYTES (NFT_REG32_COUNT * sizeof(uint32_t))
> +#define NFT_MAX_EXPR_LEN_BYTES (1UL * NFT_REG32_COUNT * sizeof(uint32_t))
I would suggest to stick to unsigned 32-bit for this.
Related, I checked that NFT_MAX_EXPR_LEN_BITS is used with uint32_t
vars after quickly browsing code here.
Then, this is used to allocate a small buffer.
unsigned char data[NFT_MAX_EXPR_LEN_BYTES];
Thanks.
> #define NFT_MAX_EXPR_LEN_BITS (NFT_MAX_EXPR_LEN_BYTES * BITS_PER_BYTE)
> #define NFT_MAX_EXPR_RECURSION 16
>
> diff --git a/src/netlink_linearize.c b/src/netlink_linearize.c
> index dfa841c6a407f..8de507059fe59 100644
> --- a/src/netlink_linearize.c
> +++ b/src/netlink_linearize.c
> @@ -31,7 +31,7 @@ struct nft_expr_loc *nft_expr_loc_find(const struct nftnl_expr *nle,
> struct nft_expr_loc *eloc;
> uint32_t hash;
>
> - hash = (uint64_t)nle % NFT_EXPR_LOC_HSIZE;
> + hash = (unsigned long)nle % NFT_EXPR_LOC_HSIZE;
> list_for_each_entry(eloc, &ctx->expr_loc_htable[hash], hlist) {
> if (eloc->nle == nle)
> return eloc;
> @@ -50,7 +50,7 @@ static void nft_expr_loc_add(const struct nftnl_expr *nle,
> eloc = xmalloc(sizeof(*eloc));
> eloc->nle = nle;
> eloc->loc = loc;
> - hash = (uint64_t)nle % NFT_EXPR_LOC_HSIZE;
> + hash = (unsigned long)nle % NFT_EXPR_LOC_HSIZE;
> list_add_tail(&eloc->hlist, &ctx->expr_loc_htable[hash]);
> }
>
> diff --git a/src/parser_bison.y b/src/parser_bison.y
> index 6e1c1cc205331..138dbfa3b70de 100644
> --- a/src/parser_bison.y
> +++ b/src/parser_bison.y
> @@ -5887,7 +5887,7 @@ payload_expr : payload_raw_expr
> payload_raw_len : NUM
> {
> if ($1 > NFT_MAX_EXPR_LEN_BITS) {
> - erec_queue(error(&@1, "raw payload length %lu exceeds upper limit of %lu",
> + erec_queue(error(&@1, "raw payload length %" PRIu64 " exceeds upper limit of %lu",
> $1, NFT_MAX_EXPR_LEN_BITS),
> state->msgs);
> YYERROR;
> diff --git a/src/scanner.l b/src/scanner.l
> index 61fcc4fa3bad3..37729ebc3cc55 100644
> --- a/src/scanner.l
> +++ b/src/scanner.l
> @@ -91,7 +91,7 @@ static void update_offset(struct parser_state *state, struct location *loc,
> uint32_t line_offset;
>
> state->indesc->token_offset += len;
> - if (state->indesc->line_offset > UINT32_MAX)
> + if (state->indesc->line_offset > (off_t)UINT32_MAX)
> line_offset = UINT32_MAX;
> else
> line_offset = state->indesc->line_offset;
> --
> 2.54.0
>
prev parent reply other threads:[~2026-09-27 19:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 17:37 [nft PATCH] Fix for warnings when compiling for 32bit arch Phil Sutter
2026-09-27 19:33 ` Pablo Neira Ayuso [this message]
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=arlvkVx3c6_TvrWU@chamomile \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/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