[musl] getpwuid() calls getline() which may be redefined

[musl] getpwuid() calls getline() which may be redefined

[Robert Clausecker]

Greetings,

I'm the maintainer of schilytools [1], a suite of tools including
cdrecord, mkisofs, star, smake, and others.  To produce Linux
binary releases for our users, I investigated building static
binaries with musl and found that the star command experienced
problems [3]: when built with

    smake LINKMODE=static LDOPTX=-static INS_RBASE=/opt/schily SHLIB_BUILD=\#

the program hangs reading from stdin.  With the help of psykose
from your IRC channel, we found that this is due to getpwuid()
calling getline(), a symbol which this program uses for a custom
function with a POSIX-incompatible signature.  This use of the
getline() symbol dates back to UNOS [2], an early UNIX close.

We'll try to work around this issue, likely by renaming our
getline() to something else.  I have filed this bug report with
you so you may decide if you wish to route the getline() call
through an internal symbol alias, proofing your library against
incompatible external redefinitions.

Yours,
Robert Clausecker

[1]: https://codeberg.org/schilytools/schilytools
[2]: https://en.wikipedia.org/wiki/UNOS_(operating_system)
[3]: https://codeberg.org/schilytools/schilytools/issues/31

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

Re: [musl] getpwuid() calls getline() which may be redefined

[Rich Felker]

On Mon, Apr 17, 2023 at 06:50:06PM +0200, Robert Clausecker wrote:
> Greetings,
> 
> I'm the maintainer of schilytools [1], a suite of tools including
> cdrecord, mkisofs, star, smake, and others.  To produce Linux
> binary releases for our users, I investigated building static
> binaries with musl and found that the star command experienced
> problems [3]: when built with
> 
>     smake LINKMODE=static LDOPTX=-static INS_RBASE=/opt/schily SHLIB_BUILD=\#
> 
> the program hangs reading from stdin.  With the help of psykose
> from your IRC channel, we found that this is due to getpwuid()
> calling getline(), a symbol which this program uses for a custom
> function with a POSIX-incompatible signature.  This use of the
> getline() symbol dates back to UNOS [2], an early UNIX close.
> 
> We'll try to work around this issue, likely by renaming our
> getline() to something else.  I have filed this bug report with
> you so you may decide if you wish to route the getline() call
> through an internal symbol alias, proofing your library against
> incompatible external redefinitions.

Thanks for the report. getline has been POSIX for 15 years now, and we
don't aim for namespace-conformance to non-latest versions of the
standard. Namespace-guarded symbols are only used where we want to
implement one function in terms of another whose name isn't reserved
under the same standards-profile. Just renaming the function on the
application side to bring it up to modern standards is the right fix
here. (And it's good to hear somebody's still maintaining Schilly's
stuff!)

Rich