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
