[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stdioext on musl
From: |
Paul Eggert |
Subject: |
Re: stdioext on musl |
Date: |
Sun, 17 Jun 2012 15:44:16 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
On 06/17/2012 02:56 PM, Rich Felker wrote:
>> 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.
OK, so why not change musl to define a symbol like __MUSL__ that
will make gnulib's job easier? The arguments given so far against
such a symbol seem to be based primarily on theoretical objections,
which don't have much practical force. The argument for having a
symbol is based on real code that we need to write.
> will configure even find them?
Yes, it can be made to find them, as part of gnulib.
> a big part of musl's design goal has been to avoid implementation
> lock-in caused by exposing internals to applications.
And a big part of gnulib's design goal is to provide useful functionality
that is portable and efficient on practical systems. These goals clash.
Sorry, but that's life. Now, we have to decide what to do about it.
To us, conforming to the standard is merely a means towards writing portable
and efficient software. If not-conforming to the standard achieves the
goal better, then we will fail to conform to the standard. For us,
standards are our servants, not our masters.
This is a pragmatic approach that works well in practice. Bruno has
ported it to musl too, which is a good thing. It would be nicer if
the port used "approved" musl interfaces, but if musl can't or won't
do that we'll just have to continue to poke under musl's covers to get
the behavior that we want, just like we do with many other libraries.
If these libraries change in the future, gnulib will too. But it would
be better if musl provided better interfaces for this useful functionality;
as that would make gnulib-based applications more likely to port to
future musl implementations without hassle.
- Re: isnanl, printf, and non-IEEE values, (continued)
- Re: isnanl, printf, and non-IEEE values, Ben Pfaff, 2012/06/18
- Re: musl printf bugs, Bruno Haible, 2012/06/17
- Re: musl printf bugs, Rich Felker, 2012/06/17
- Re: musl printf bugs, Bruno Haible, 2012/06/17
- Re: getopt.m4 test, Bruno Haible, 2012/06/19
- Re: getopt.m4 test, Bruno Haible, 2012/06/23
- Re: getopt.m4 test, Paul Eggert, 2012/06/23
- Re: getopt.m4 test, Bruno Haible, 2012/06/26
Re: stdioext on musl, Bruno Haible, 2012/06/17
Re: stdioext on musl, Bruno Haible, 2012/06/17
Re: stdioext on musl, Rich Felker, 2012/06/17
Re: stdioext on musl, Bruno Haible, 2012/06/17
Re: stdioext on musl, Rich Felker, 2012/06/17
Re: stdioext on musl [was: gnulib portability issues], John Spencer, 2012/06/18
Re: stdioext on musl [was: gnulib portability issues], Paul Eggert, 2012/06/18