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
stdioext: Add support for musl libc.
* m4/fbufmode.m4 (gl_FUNC_FBUFMODE): Test whet
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
>
> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e
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 su
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.
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 i
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 rea
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 h
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
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 th
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_ work
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
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
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
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 vis
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
>
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.
> Ho
16 matches
Mail list logo
