bug-gnulib
[Top][All Lists]
Advanced

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

Re: stdioext on musl


From: Rich Felker
Subject: Re: stdioext on musl
Date: Sun, 17 Jun 2012 20:18:43 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jun 18, 2012 at 02:01:28AM +0200, Bruno Haible wrote:
> 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.

OK, that sounds reasonable.

Would you also be willing to get the fallback cases for these working?
I believe you're already using a variant of an algorithm I designed a
long time ago for emulating fseterr in the SLOW_BUT_NO_HACKS case.
There was also a discussion earlier on this list with a similar
fallback for freadahead that would work on all systems (but only
returning 0/1, not an actual buffered byte count), and of course
freadptr can fallback to returning NULL. I agree these implementations
are horribly slow and undesirable, but it would be nice if the next
new system that runs into trouble with gnulib-based programs is coming
to you with "What do we need to do to get gnulib to be fast on our
system?" rather than "Dammit why is gnulib throwing #error in the
default case?!"

> 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?

I think assuming the function works whenever it exists is probably a
sane default for cross-compiling, but perhaps you have experience with
hideous systems contrary to this seemingly-natural line of thinking...

> 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

Would you mind telling me how it's different and how that's a problem?
I meant for these functions to follow the traditional stdio_ext.h API,
and if they're not doing the right thing I'd rather fix them than have
ugly workarounds going into gnulib.

Is the issue that you want __fwriting to return 1 even if there's no
data buffered as long as the last action on the file was a write? If
so, I think I can easily fix that.

Rich



reply via email to

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