[musl] Bug?: weak alias fpurge() may better be removed

[musl] Bug?: weak alias fpurge() may better be removed

[Jun. T]

fpurge() exists as a weak_alias in stdio/ext.c, but it is not
declared in any header files. This causes a problem when building,
for example, zsh:

AC_CHECK_FUNCS(fpurge) finds the alias and defines HAVE_FPURGE,
but compiling a C code using fpurge() fails since it can't be
found in any headers.

It seems fpurge() is removed from stdio.h by an old commit:
a34b0465ba14c70532b8eaba650a9eac228fce57

Is there any reason that the weak_alias needs be kept?

Re: [musl] Bug?: weak alias fpurge() may better be removed

[Rich Felker]

On Fri, Oct 03, 2025 at 08:42:03AM +0900, Jun. T wrote:
> fpurge() exists as a weak_alias in stdio/ext.c, but it is not
> declared in any header files. This causes a problem when building,
> for example, zsh:
> 
> AC_CHECK_FUNCS(fpurge) finds the alias and defines HAVE_FPURGE,
> but compiling a C code using fpurge() fails since it can't be
> found in any headers.
> 
> It seems fpurge() is removed from stdio.h by an old commit:
> a34b0465ba14c70532b8eaba650a9eac228fce57
> 
> Is there any reason that the weak_alias needs be kept?

If anything has linked to it, removing the symbol would break those
binaries. I'm not sure if this is justifiable. Configure tests that
just check for linkability without testing for successful compilation
are buggy and really really need to be fixed. They will cause massive
breakage when the right feature-test macros are not defined to expose
symbols the program is going to try to use, especially with modern gcc
and clang versions that default to disallowing implicit function
declarations.

Rich

Re: [musl] Bug?: weak alias fpurge() may better be removed

[Rich Felker]

On Sun, Oct 05, 2025 at 06:38:38PM +0900, Jun. T wrote:
> 
> > 2025/10/03 10:09、Rich Felker <dalias@libc.org>のメール:
> > 
> > If anything has linked to it, removing the symbol would break those
> > binaries. I'm not sure if this is justifiable. Configure tests that
> > just check for linkability without testing for successful compilation
> > are buggy and really really need to be fixed. They will cause massive
> > breakage when the right feature-test macros are not defined to expose
> > symbols the program is going to try to use, especially with modern gcc
> > and clang versions that default to disallowing implicit function
> > declarations.
> 
> If any project are using fpurge(), they must supply a prototype
> declaratgion by themselvs. I believe chances are very low. Instead,
> they will use __fpurge(). fpurge(3) manpage clearly states that fpurge()
> is not available (as in GNU libc).

It seems whatever software you're trying to build that was checking
for presence of the symbol was trying to use it. And a quick grep of
/usr/bin on my Alpine system shows that a bunch of binaries from
coreutils have references to the fpurge symbol. Removing it would
thereby produce a completely broken system. I don't think this is
viable.

Whatever configure test is detecting it should be fixed so that future
binaries don't get built attempting to use it without a declaration.
If this is done, they won't care if the symbol is there or not. As I
explained before, this kind of broken configure test can produce
serious bugs *even with symbols that were intended to be public* when
they're not exposed by the headers in the FTM profile the software is
being built with (e.g. if they try to use splice() without _GNU_SOURCE
or _ALL_SOURCE).

Rich

Re: [musl] Bug?: weak alias fpurge() may better be removed

[Jun T]

> 2025/10/07 10:23, Rich Felker <dalias@libc.org> wrote:

>  And a quick grep of
> /usr/bin on my Alpine system shows that a bunch of binaries from
> coreutils have references to the fpurge symbol.

Isn't there only one big binary of coreutils?
coreutils may be using its own fpurge() (from gnulib), but I'm
not 100% sure. Anyway, I don't insist that fpurge alias must be
removed immediately, but I believe it's better to remove it in
the long run.
Thank you for your time.

Re: [musl] Bug?: weak alias fpurge() may better be removed

[Jun. T]

This is just for reference:

> 2025/10/08 11:49, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
> 
> coreutils may be using its own fpurge() (from gnulib),

coreutils uses fpurge() from gnulib, but it just calls __fpurge()
of musl and returns, so it is usually optimized out by the
compiler. If I build (on Alpine) coreutils without optimization
(-O0) I can find rpl_fpurge in the symbol table (rpl_fpurge
is the name of fpurge() from gnulib).