All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: aurelien@hackers.camp, openembedded-core@lists.openembedded.org
Cc: aurelien.desbrieres@gmail.com
Subject: Re: [OE-core] [PATCH] flex: fix stage1flex build under a C23 default
Date: Sun, 13 Sep 2026 21:21:21 +0100	[thread overview]
Message-ID: <3d12110d88ce771519ccedb12e7b6d0d24d7d17a.camel@linuxfoundation.org> (raw)
In-Reply-To: <20260913160558.2569053-1-aurelien@hackers.camp>

On Sun, 2026-09-13 at 18:05 +0200, Aurelien DESBRIERES via lists.openembedded.org wrote:
> lib/malloc.c declares "void *malloc ();" with an empty parameter list
> and calls it with one argument. That meant "unspecified" in C89 and
> means "none" in C23, so the call is rejected:
> 
>   lib/malloc.c:16:15: error: too many arguments to function 'malloc';
>                              expected 0, have 1
> 
> It is the language mode that decides, not the compiler version: the
> same GCC 16 compiles the file with -std=gnu17 and rejects it with
> -std=gnu23. GCC 15 made gnu23 the default, so every host from that
> release on hits it while GCC 14 does not.
> 
> The file is compiled by stage1flex -- the bootstrap scanner flex builds
> with the host compiler before it can build itself -- so neither CFLAGS
> nor BUILD_CFLAGS reaches that command line and no flag in the recipe
> can silence it.
> 
> stdlib.h has the right declaration and the file already includes
> sys/types.h for size_t. lib/realloc.c includes stdlib.h already and
> needs no change.
> 
> Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp>
> ---
>  ...b-malloc-declare-malloc-via-stdlib.h.patch | 38 +++++++++++++++++++
>  meta/recipes-devtools/flex/flex_2.6.4.bb      |  1 +
>  2 files changed, 39 insertions(+)
>  create mode 100644 meta/recipes-devtools/flex/flex/0001-lib-malloc-declare-malloc-via-stdlib.h.patch
> 
> diff --git a/meta/recipes-devtools/flex/flex/0001-lib-malloc-declare-malloc-via-stdlib.h.patch b/meta/recipes-devtools/flex/flex/0001-lib-malloc-declare-malloc-via-stdlib.h.patch
> new file mode 100644
> index 0000000000..a64d6220a8
> --- /dev/null
> +++ b/meta/recipes-devtools/flex/flex/0001-lib-malloc-declare-malloc-via-stdlib.h.patch
> @@ -0,0 +1,38 @@
> +From: Aurelien Desbrieres <aurelien@hackers.camp>
> +Date: Sat, 13 Sep 2026 00:00:00 +0200
> +Subject: [PATCH] lib/malloc.c: declare malloc via stdlib.h
> +
> +The gnulib fallback declares "void *malloc ();" with an empty parameter
> +list and calls it with one argument. That meant "unspecified" in C89 and
> +means "none" in C23, which GCC 14 and later implement by default, so the
> +call is rejected:
> +
> +  lib/malloc.c:16:15: error: too many arguments to function 'malloc';
> +                             expected 0, have 1
> +
> +stdlib.h has the right declaration and the file already includes
> +sys/types.h for size_t, so the local one has nothing to add.
> +lib/realloc.c includes stdlib.h already and needs no change.
> +
> +The file is dead code wherever malloc(0) returns non-NULL -- glibc
> +included -- since AC_FUNC_MALLOC substitutes rpl_malloc only where it
> +does not, but it is compiled regardless and the build stops there.
> +
> +Upstream-Status: Inappropriate [flex 2.6.4 is the last release, 2017]

I'm not sure I follow that reasoning. It might be better to follow what
upstream did:

https://github.com/westes/flex/commit/bf254c75b1e0d2641ebbd7fc85fb183f36a62ea7

so this patch is then a backport and will fall out if/as/when we do see
another release of flex?

Cheers,

Richard




  reply	other threads:[~2026-09-13 20:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13 16:05 [PATCH] flex: fix stage1flex build under a C23 default Aurelien DESBRIERES
2026-09-13 20:21 ` Richard Purdie [this message]
2026-09-14  8:53   ` [PATCH v2] flex: backport the upstream malloc prototype fix Aurelien DESBRIERES
2026-09-15  7:37     ` [OE-core] " Antonin Godard
2026-09-15  7:49       ` Aurelien DESBRIERES

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=3d12110d88ce771519ccedb12e7b6d0d24d7d17a.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=aurelien.desbrieres@gmail.com \
    --cc=aurelien@hackers.camp \
    --cc=openembedded-core@lists.openembedded.org \
    /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.