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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.