Re: stdioext on musl

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

Re: stdioext on musl

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

Re: stdioext on musl

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

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

Re: [musl] Re: musl bugs found through gnulib

> [CCing the musl list] > Isaac Dunham wrote in > : >> musl is designed for standards conformance, > > There is a recipe, in , > that explains how to use gnulib to check a libc again

Re: [musl] Re: musl bugs found through gnulib

> [CCing the musl list] > Isaac Dunham wrote in > : >> musl is designed for standards conformance, > > There is a recipe, in , > that explains how to use gnulib to check a libc again

Re: stdioext on musl

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

Re: stdioext on musl

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

Re: isnanl, printf, and non-IEEE values

Rich Felker wrote: > > > So isnanl is expected to be slower in every program that's using it > > > for legitimate arithmetic purposes > > > > Yes. But it will not be slower by much. The CPUs have an instruction for > > 'fpclassify'; you just need to pass the right bitmask to that instruction. > >

Re: stdioext on musl

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: isnanl, printf, and non-IEEE values

On 06/17/2012 03:41 PM, Rich Felker wrote: > No program I know of reads long double directly from binary files. 'od -tfL' does. I'm sure there are others. It's pretty common to save binary data into files and restore it later.

Re: stdioext on musl

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: musl printf bugs

Rich Felker wrote: > > checking whether printf supports the 'ls' directive... no > > Yep, I caught this one a while back. It's fixed in git. Good to hear that. Bruno

Re: musl bugs found through gnulib

[CCing the musl list] Isaac Dunham wrote in : > musl is designed for standards conformance, There is a recipe, in , that explains how to use gnulib to check a libc against bugs. Whe

Re: isnanl, printf, and non-IEEE values

On Sun, Jun 17, 2012 at 11:33:45PM +0200, Bruno Haible wrote: > The other justification for handling these representations was brought up > by Jim in the long thread that surrounded this glibc bug: > >

Re: stdioext on musl

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

Re: musl printf bugs

On Sun, Jun 17, 2012 at 11:57:05PM +0200, Bruno Haible wrote: > Rich Felker wrote: > > considering printf broken, and replacing printf > > because of this, is a big issue. Replacing printf is non-trivial > > There is also another test that causes musl's printf to be overridden: > > checking whe

Re: stdioext on musl

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: musl printf bugs

Rich Felker wrote: > considering printf broken, and replacing printf > because of this, is a big issue. Replacing printf is non-trivial There is also another test that causes musl's printf to be overridden: checking whether printf supports the 'ls' directive... no The test program exited with

Re: Why require SLOW_BUT_NO_HACKS for stubs?

Isaac Dunham wrote: > > The test as it stands is "error out on unsupported platforms unless > > user specifies to use slow method". > > My proposal is "On unsupported platforms, use the slow method instead > > of erroring out." If we did this, nobody would report to bug-gnulib (or to the libc main

Re: isnanl, printf, and non-IEEE values

Rich Felker wrote: > > > 2. Several tests for isnanl and printf long double support are > > > invalid. They are generating invalid LD80 representations that cannot > > > occur as values ("pseudo-denormal", for example) and testing that > > > isnanl and printf treat these as NAN. Per the C standard,

Re: stdioext to POSIX

Eric Blake wrote: > Furthermore, I'm considering writing a proposal for the next version of > POSIX to standardize several of the stdio functions currently provided > by gnulib, along with rationale why they are useful and how they can be > used to speed up programs. The fact that gnulib is an exi

Re: gnulib portability issues

Hi Paul, > > They're purposefully opaque so that they can be changed if an > > alternate implementation proves better. > > Dragonfly BSD attacked this problem by supplying a > function __sreadahead that returns the value in question. > Perhaps musl could do something similar? That would fix > th

Re: stdioext on musl

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

[PATCH] maint.mk: fix typo in code to derive GPG key at release time

FYI, since I let the default GPG-key-deriving code get my key from the just-created tag (the default), I noticed that it was broken. This fix matters only at release time, and if you don't set gpg_key_ID in cfg.mk: >From 5eae670f051c94b73d7dd6aae2d4a814ca691f9e Mon Sep 17 00:00:00 2001 From: Jim M

Re: regcomp warnings using Mingw64 toolchain

On 06/17/2012 07:00 AM, Bruno Haible wrote: > For portability the cast to 'long' should better be replaced with a cast > to 'intptr_t'. Thanks, I did that, except I used uintptr_t since the value in question is a size_t value. regex: avoid warning when pointers are not long * lib/regcomp.c (parse

Re: string buffer

Pádraig Brady wrote: > Since there are lots of appending of strings here, > the approach taken in coreutils so far was > to append in a large buffer allocated up front, > or just to write to stdout. > > I guess something in between is more appropriate for a lib. > I.E. efficiently append to a stri

Re: musl compatibility

Paul Eggert wrote: > On 06/12/2012 04:21 AM, Paolo Bonzini wrote: > > perhaps we can follow the suggestion and > > replace "if (freadahead (f))" with "if (freading(f) && !feof(f))" in > > closein.c. > > Yes, thanks, I like this idea the best of those suggested so far. > Here's a proposed patch to

Re: Licensing of dummy.c

Hi Jim, Reuben, > > Since this file is trivial, would it be possible to give it an > > all-permissive license? Someone has just (helpfully!) pointed out that > > it shouldn't be in a BSD-licensed project I maintain, where it gets > > pulled in by bootstrap. > > If dummy's license is causing troub

Re: new module: relpath

On 06/17/2012 10:54 AM, Bruno Haible wrote: > Hi Pádraig, > >>> concat-filename >>> filename >>> filenamecat >>> It would be good to choose a module name in this spirit. >> >> I suppose relname would be most appropriate given that argument, >> though I think in this case it's slightly better

Re: Libvirt / GNULIB failures using Mingw64 toolchain

Hello Daniel, > CC fstat.lo > ../../../gnulib/lib/fstat.c:27:0: warning: "stat" redefined [enabled by > default] > In file included from ./sys/stat.h:32:0, > from ../../../gnulib/lib/fstat.c:25: > /usr/x86_64-w64-mingw32/sys-root/mingw/include/sys/stat.h:258:0: note: this

Re: new module: relpath

On 06/17/2012 03:02 PM, Jim Meyering wrote: > Akim Demaille wrote: >> Le 16 juin 2012 à 17:25, Bruno Haible a écrit : >>> Hi Akim, >> Hi Bruno, >> Thanks for the detailed comments. > ... +Depends-on: +canonicalize +dirname +error +pathmax +stdbool +xalloc +..

Re: new module: relpath

Akim Demaille wrote: > Le 16 juin 2012 à 17:25, Bruno Haible a écrit : >> Hi Akim, > Hi Bruno, > Thanks for the detailed comments. ... >>> +Depends-on: >>> +canonicalize >>> +dirname >>> +error >>> +pathmax >>> +stdbool >>> +xalloc >>> +... >>> +License: >>> +GPLv3+ >> >> This module may produce er

Re: regcomp warnings using Mingw64 toolchain

Hi Paul, Daniel P. Berrange wrote: > While on x86_64-w64-mingw32 only I see: > > > In file included from ../../../gnulib/lib/regex.c:69:0: > ../../../gnulib/lib/regcomp.c: In function 'parse_dup_op': > ../../../gnulib/lib/regcomp.c:2624:39: warning: cast to pointer from integer > of different s

Re: new module: relpath

Hi Pádraig, > > concat-filename > > filename > > filenamecat > > It would be good to choose a module name in this spirit. > > I suppose relname would be most appropriate given that argument, > though I think in this case it's slightly better to keep the relpath name > so as to align with si

Re: new module: relpath

Hi Pádraig! Le 16 juin 2012 à 18:15, Pádraig Brady a écrit : > On 06/16/2012 04:25 PM, Bruno Haible wrote: >> I agree that >> 1. this is general-purpose functionality that has its place in gnulib, >> 2. when you start to copy code from coreutils to bison, it's time to >> move it to gnulib,

Re: new module: relpath

Le 16 juin 2012 à 17:25, Bruno Haible a écrit : > Hi Akim, Hi Bruno, Thanks for the detailed comments. > About the module name 'relpath': The GNU standards, section "GNU Manuals", > say > Please do not use the term "pathname" that is used in Unix > documentation; use "file name" (two words