Re: stdioext on musl

2012-06-19 Thread Bruno Haible
Hi Rich, The patches that you've committed at http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=deb90c79e5c498fbb48de1423df034447f330e38 http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e15171b8d8e80e8b5bcf4e95b1709697858f545a go a long way at implementing the

Re: stdioext on musl

2012-06-19 Thread Rich Felker
On Tue, Jun 19, 2012 at 01:46:40PM +0200, Bruno Haible wrote: Hi Rich, The patches that you've committed at http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=deb90c79e5c498fbb48de1423df034447f330e38

Re: stdioext on musl

2012-06-19 Thread Bruno Haible
Rich Felker wrote: stdio_ext.h okay? OK, of course. With these patches from your side, I am applying these changes to gnulib. No need for #ifdef __MUSL__ for now. 2012-06-19 Bruno Haible br...@clisp.org stdioext: Add support for musl libc. * m4/fbufmode.m4

Re: stdioext on musl [was: gnulib portability issues]

2012-06-18 Thread John Spencer
On Sun, 17 Jun 2012 16:59:45 -0700, Bruno Haible wrote Rich Felker wrote If gnulib is willing to _detect_ working functions rather than trying to detect musl [...] We often, but not always, use an autoconf test that verifies that a function works. Why not always? Because such a test is

Re: stdioext on musl [was: gnulib portability issues]

2012-06-18 Thread Paul Eggert
On 06/18/2012 06:27 AM, John Spencer wrote: I just couldn't withstand to express my disgust Please refrain from such rhetoric in the future. The bug-gnulib mailing list is for discussing ways to improve gnulib, and personal attacks get in the way of its purpose.

Re: stdioext on musl

2012-06-17 Thread Bruno Haible
Rich Felker wrote: 1. freadahead is inherently non-portable and has no working portable fallback version. At some point in the discussions, it was suggested that this function should not be pulled in except on old broken systems where stdio doesn't work and needs replacement functions.

Re: stdioext on musl

2012-06-17 Thread Rich Felker
On Sun, Jun 17, 2012 at 10:56:48PM +0200, Bruno Haible wrote: Rich Felker wrote: 1. freadahead is inherently non-portable and has no working portable fallback version. At some point in the discussions, it was suggested that this function should not be pulled in except on old broken

Re: stdioext on musl

2012-06-17 Thread Paul Eggert
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

Re: stdioext on musl

2012-06-17 Thread Rich Felker
On Sun, Jun 17, 2012 at 03:44:16PM -0700, Paul Eggert wrote: will configure even find them? Yes, it can be made to find them, as part of gnulib. I mean will it find them without needing a special macro like __MUSL__? This is a pragmatic approach that works well in practice. Bruno has

Re: stdioext on musl

2012-06-17 Thread Paul Eggert
On 06/17/2012 03:53 PM, Rich Felker wrote: By better interfaces do you mean the 4 already-mentioned stdio extension functions, or something else? Yes, I mean the functions that Bruno mentioned. I mean will it find them without needing a special macro like __MUSL__? Having a symbol like

Re: stdioext on musl

2012-06-17 Thread Rich Felker
On Sun, Jun 17, 2012 at 04:10:52PM -0700, Paul Eggert wrote: On 06/17/2012 03:53 PM, Rich Felker wrote: By better interfaces do you mean the 4 already-mentioned stdio extension functions, or something else? Yes, I mean the functions that Bruno mentioned. I mean will it find them

Re: stdioext on musl

2012-06-17 Thread Bruno Haible
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

Re: stdioext on musl

2012-06-17 Thread Rich Felker
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

Re: stdioext on musl

2012-06-17 Thread Bruno Haible
Rich, Then Bruno came back to us with this monstrosity of a patch that insists, for no good reason, on trying to detect musl specifically, thereby increasing the amount of broken special-cased non-portable code in gnulib rather than modernizing it. ... What is my business is that Bruno

Re: stdioext on musl

2012-06-17 Thread Bruno Haible
Rich Felker wrote: 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

Re: stdioext on musl

2012-06-17 Thread Rich Felker
On Mon, Jun 18, 2012 at 02:59:56AM +0200, Bruno Haible wrote: For 2), the issue is that for a stream opened in write-only mode, immediately after the fopen() call, gnulib expects fwriting(fp) to be true: Thanks. I committed a change whereby __freading now returns 1 whenever the stream is