bug-gnulib
[Top][All Lists]
Advanced

[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.




reply via email to

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