bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stdioext on musl


From: Bruno Haible
Subject: Re: stdioext on musl
Date: Mon, 18 Jun 2012 02:01:28 +0200
User-agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; )

Rich Felker wrote:
> > 2) Provide 4 primitive functions.
> 
> This is less offensive at least, but will configure even find them?
> Eric Blake offered to make it work that way, but you seem to want to
> test against macros that identify the implementation...? If gnulib is
> willing to _detect_ working functions rather than trying to detect
> musl, I'd be willing, albeit reluctant, to add them.

If you accept the proposed function names __freadahead, __freadptr,
__freadptrinc, __fseterr, then we will start by using an autoconf check,
and use the obvious conditionals like
  #if HAVE___FREADPTR
in the code. This way, if other libcs do the same, gnulib will not have
to change much.

But it is in our discretion to use #ifdef __MUSL__ instead. For example,
hypothetically speaking, if all other libc authors create incompatible
or buggy variants of __freadptr. Then we may want to use #ifdef __MUSL__.

We often, but not always, use an autoconf test that verifies that a
function works. Why not always? Because such a test is ca. 20-50 lines of
code, and a #ifdef is just 1 line of code.

Additionally, we need the #ifdef for platforms that are cross-compilation
targets (because AC_RUN_IFELSE's 4th argument is a cross-compilation guess).
I believe musl is a candidate for cross-compilation, due to its small size?

> > 1) Currently, gnulib has to go to a great length to detect musl.
> >    It uses the presence of __stdio_read and __stdio_write as an indicator;
> 
> That's not valid. These are internal functions that could be renamed
> or disappear (e.g. be changed to visibility=hidden) at any time.

Yup. That's precisely why we need an indicator such as __MUSL__.

> I hope it doesn't sound like I'm just being pedantic here. All along,
> a big part of musl's design goal has been to avoid implementation
> lock-in caused by exposing internals to applications. By keeping the
> interface basically just the standard C and POSIX functions, ...

You are not alone on the world. Some other people may well do the same.
Then we have two libcs, which both don't identify themselves. And in real
life, there are bugs that gnulib needs to work around. So gnulib needs a
way to distinguish your libc from the other guys' libc.

This is not hypothetical at all. The __freading, __fwriting functions
exist in various libcs (glibc, Solaris, uClibc, musl). But only in musl
the value is different in some particular case. Therefore I ask you to
spent 1 line of code to identify musl. Or, you can contribute the two
autoconf tests - written according to gnulib standards and with a
reasonable cross-compilation default - that will allow gnulib to
distinguish the glibc, Solaris, uClibc __freading / __fwriting functions
from the musl one.

> Then either test that __freading works, or use something like
> 
> #if defined(__GLIBC__) && __GLIBC__MAJOR__ == 2 && __GLIBC_MINOR__ < 7
> 
> to special-case the workaround only for particular known broken
> versions, and otherwise assume it works.

Yes we want to assume, in general, that a function works. BUT
  1) in the case of __fwriting, musl 0.9.1 is among the platforms
     which are "known broken" (means, not exactly like gnulib expects),
  2) when cross-compiling, we would like to have a conservative guess
     that classifies all musl versions as "possibly bad, better not use"
     and all other platforms as "likely OK".

For this purpose, we need a macro such as __MUSL__.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]