flex: fix stage1flex build under a C23 default

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

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