Re: [musl] Re: parse-datetime test failure

On Wed, Nov 11, 2020 at 07:38:00PM -0800, Paul Eggert wrote: > On 11/11/20 8:20 AM, Bruno Haible wrote: > >It works fine on Alpine Linux 3.7 (32-bit, 64-bit) and 3.9 (64-bit). > > > >On Alpine Linux 3.10 and 3.12 (64-bit) it fails: > >../../gltests/test-parse-datetime.c:448: assertion 'result.tv_se

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote: > On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote: > > * Paul Eggert: > > > > > On 1/22/20 2:05 PM, Rich Felker wrote: > > >> I think we're approaching a consensus that glibc sho

Re: bug#39236: [musl] coreutils cp mishandles error return from lchmod

On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote: > * Paul Eggert: > > > On 1/22/20 2:05 PM, Rich Felker wrote: > >> I think we're approaching a consensus that glibc should fix this too, > >> so then it would just be gnulib matching the fix. > &

Re: [musl] Re: posix_spawn_file_actions_add* functions on musl libc

On Sun, Mar 24, 2019 at 07:23:16PM +0100, Bruno Haible wrote: > Hi Rich, > > > -- it would preclude advance creation of a file actions object which > > will open or dup onto high fd numbers at a later time after the rlimit > > has been increased. > > This is a highly theoretical use-case, isn't i

Re: posix_spawn_file_actions_add* functions on musl libc

On Sat, Mar 23, 2019 at 09:46:28PM +0100, Bruno Haible wrote: > The gnulib configure test in m4/posix_spawn.m4, when run on Alpine Linux 3.7, > determines that the posix_spawn_file_actions_add* functions do not fail as > expected for an out-of-range file descriptor. The POSIX "shall fail" requirem

Re: [musl] Re: localename: add support for musl libc

On Sun, Feb 25, 2018 at 10:19:06PM +0100, Bruno Haible wrote: > Hi Rich, > > > Really use of NL_LOCALE_NAME should always be preferred if it's > > available, since it's a clean public interface for the functionality > > desired rather than a hack poking at implementation internals. But if > > you

Re: localename: add support for musl libc

On Sun, Feb 25, 2018 at 11:17:08AM +0100, Bruno Haible wrote: > Hi Assaf, > > > > +# elif defined __linux__ && HAVE_LANGINFO_H && defined NL_LOCALE_NAME > > > +/* musl libc */ > > > > A tiny comment about the comment :) > > > > You wrote "musl libc", but what the "elif defined ..." is s

Re: Hanging conftest

On Wed, Dec 04, 2013 at 03:38:33AM +, Pádraig Brady wrote: > Ah so mallopt(M_CHECK_ACTION, 2) is documented to abort() on error. > I suppose we need to suppress core dumps now with the gnulib > ]GL_NOCRASH[ ... nocrash_init() guard? > Actually no, that doesn't catch SIGABRT. > So I suppose you

Re: gnulib cross-compiling issue with musl

On Tue, Jun 18, 2013 at 01:09:10PM -0700, Paul Eggert wrote: > On 06/18/13 11:42, Rich Felker wrote: > > if > > you think it matters, you could add #elif defined _POSIX_VERSION > > containing the if(0) > > Yes, that should work, though it needs to check a couple ore

Re: gnulib cross-compiling issue with musl

On Tue, Jun 18, 2013 at 11:32:50AM -0700, Paul Eggert wrote: > On 06/18/13 11:07, Rich Felker wrote: > > > Of my two > > proposed fixes, the first would fix the issue on any future system > > that's not broken (not just existing ones), but would obviously not >

Re: gnulib cross-compiling issue with musl

On Tue, Jun 18, 2013 at 10:41:45AM -0700, Paul Eggert wrote: > On 06/18/13 10:03, Rich Felker wrote: > > 1. In the #else case, instead of #error, put if(0) > > 2. Write a "portable" version of the replacement code > > How about this idea instead? > > 3.

gnulib cross-compiling issue with musl

Hi again, Last year after a great deal of discussion, we got most of the issues between gnulib and musl libc fixed. However there's one problem that keeps coming up again and again from our users: when cross-compiling, gnulib treats fseeko (well, actually fflush(stdin), which in turn requires a re

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

On Wed, Jun 20, 2012 at 03:28:02PM -0400, Rich Felker wrote: > > Replacement of getcwd, because of > > checking whether getcwd handles long file names properly... no, but it is > > partly working This test is failing because musl uses the kernel to resolve the current direc

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

On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > [CCing the musl list] > Isaac Dunham wrote in > : > > musl is designed for standards conformance, > > There is a recipe, in

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

On Tue, Jun 19, 2012 at 10:10:11PM -0600, Eric Blake wrote: > Unfortunately, you are out of date. POSIX _does_ require > duplocale(LC_GLOBAL_LOCALE) to work: > > http://austingroupbugs.net/view.php?id=301 OK. I'll add support. For now all it requires is avoiding dereferencing the pointer, anyway

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

Some more updates.. On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > Replacements of *printf, because of > [...] > checking whether printf survives out-of-memory conditions... no This was caused by the pointer-arithmetic overflow bug I just fixed in git. It should no longer fail,

Re: musl, printf out-of-memory test

On Tue, Jun 19, 2012 at 11:17:33PM +0200, Bruno Haible wrote: > [...] > The SIGSEGV occurs because d = 0x218b40 but the address ranges are these: > 08048000-08049000 r-xp 08:05 26174991 > /data/bruno/tmp/testdir3/conftest > 08049000-0804b000 rwxp 08:05 2

Re: musl, printf out-of-memory test

On Tue, Jun 19, 2012 at 10:04:57PM +0200, Bruno Haible wrote: > I can reduce the program and the compilation options: > > === conftest.c = > #include > #include > int main() > { > int ret; > int err; > ret = printf ("%.500f", 1.0)

Re: [musl] Re: musl, printf out-of-memory test

On Tue, Jun 19, 2012 at 12:45:50PM +0200, Bruno Haible wrote: > So, the exit code 1 must have come from the crash handler. Without this crash > handler: 7x I get > > configure:8919: checking whether printf survives out-of-memory conditions > configure:8979: /arch/x86-linux/inst-musl/bin/musl-g

Re: rationale for closein

On Tue, Jun 19, 2012 at 06:11:35AM -0600, Eric Blake wrote: > On 06/18/2012 09:30 PM, Rich Felker wrote: > > >> > >> And that's where I disagree - the POSIX folks _specifically_ recommend > >> the closeout approach of an atexit() handler: > > >

Re: stdioext on musl

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

Re: rationale for closein

On Mon, Jun 18, 2012 at 08:17:25PM -0600, Eric Blake wrote: > On 06/18/2012 06:01 PM, Rich Felker wrote: > > > > > If the "closeout" approach works best for coreutils, that's the > > business of the coreutils' maintainers, not my business. However,

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

On Mon, Jun 18, 2012 at 08:07:40PM -0600, Eric Blake wrote: > On 06/18/2012 06:11 PM, Rich Felker wrote: > > Some updates... > > > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > >> There is a recipe, in <http://sourceware.org/glibc/wiki/Testin

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

Some updates... On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > There is a recipe, in , > that explains how to use gnulib to check a libc against bugs. When I apply > this to musl-0.9.1, I get this list of problems: > > Replacements

Re: rationale for closein

On Tue, Jun 19, 2012 at 01:28:24AM +0200, Bruno Haible wrote: > Rich Felker wrote in > <http://www.openwall.com/lists/musl/2012/06/18/8>: > > I've already discussed on this list why using an atexit function for > > closing stdin or stdout is the heart of the problem

Re: isnanl, printf, and non-IEEE values

On Mon, Jun 18, 2012 at 10:21:34AM -0700, Ben Pfaff wrote: > Bruno Haible writes: > > > In theory you would be right that data should be validated at the boundaries > > of the program, that is, when they are read from outside sources. But no > > program I know of does this for unconstrained float

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

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 w

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 mentio

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: 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: 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 o

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

Re: gnulib portability issues

On Tue, Jun 12, 2012 at 09:07:05AM -0600, Eric Blake wrote: > On 06/12/2012 08:20 AM, Rich Felker wrote: > > > To me, the only difference is the pain of replacing them. You cannot > > have these bit patterns in an LD80 without your program having invoked > > undefine

Re: gnulib portability issues

On Tue, Jun 12, 2012 at 08:02:58AM -0600, Eric Blake wrote: > > If you were just using gnulib to replace isnanl in od, it wouldn't be > > such an issue. But considering printf broken, and replacing printf > > because of this, is a big issue. Replacing printf is non-trivial, and > > might not even w

Re: gnulib portability issues

On Tue, Jun 12, 2012 at 06:12:39AM -0600, Eric Blake wrote: > And this simple program proves that most libc know how to push back more > than one byte, whether or not they differ from the original contents, > and especially in the common case where the byte still fits in the > buffer. It's the cor

Re: gnulib portability issues

On Tue, Jun 12, 2012 at 06:21:24AM -0600, Eric Blake 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

Re: gnulib portability issues

On Mon, Jun 11, 2012 at 07:14:56AM -0600, Eric Blake wrote: > On 06/11/2012 06:54 AM, Rich Felker wrote: > > >> GNU M4 (at least the master branch, although it has not yet been > >> released as m4 2.0) _wants_ to use freadahead, because it provides at > >> leas

Re: gnulib portability issues

On Mon, Jun 11, 2012 at 06:13:03AM -0600, Eric Blake wrote: > On 06/10/2012 06:43 AM, Rich Felker wrote: > > >> Come to think of it, a variant might even work for seekable files. > >> Use dup2 to move the file descriptor somewhere else. Close the > >> fd. Keep r

Re: gnulib portability issues

On Mon, Jun 11, 2012 at 06:10:02AM -0600, Eric Blake wrote: > On 06/09/2012 10:25 PM, Rich Felker wrote: > > > While fixing the underlying freadahead function would be nice, it > > might be better to make sense of WHY it's needed/wanted, if it's even > > actually

Re: gnulib portability issues

On Sun, Jun 10, 2012 at 07:02:32PM -0700, Paul Eggert wrote: > On 06/10/2012 06:10 AM, Rich Felker wrote: > > As such, the first fix I would recommend is simply removing the check > > for freadahead(stdin)>0 from closein.c > > But that will hurt performance on GNU/Linux a

Re: gnulib portability issues

On Sat, Jun 09, 2012 at 10:01:38PM -0700, Paul Eggert wrote: > > it might be better to make sense of WHY it's needed/wanted > > Yes, quite true, but that information wasn't communicated to the > gnulib mailing list. For GNU m4, it seems freadahead is not used directly. Instead, it's pulled in by

Re: gnulib portability issues

On Sat, Jun 09, 2012 at 10:01:38PM -0700, Paul Eggert wrote: > On 06/09/2012 09:25 PM, Rich Felker wrote: > > For seekable input, comparing ftello(f) and the underlying fd offset > > from lseek(fileno(f),0,SEEK_CUR) would work, but that also will fail > > for non-seekab

Re: gnulib portability issues

On Sat, Jun 09, 2012 at 09:06:21PM -0700, Paul Eggert wrote: > Patches for any of these problems would be welcome. > As freadahead seems to be most pressing, it sounds > like that's the best one to work on first. > > > 1. freadahead is inherently non-portable > > That sounds like a challenge! Ho

gnulib portability issues

Hi, Reuben suggested I contact upstream since we've been discussing on the musl mailing list (m...@lists.openwall.com, archive at http://www.openwall.com/lists/musl/) some of the difficulties that have arisen out of gnulib and programs using it when building on musl (http://www.etalabs.net/musl/).

Re: bug#7928: mktime test in configure: UB resulting in infinite loop

On Fri, Jan 28, 2011 at 06:57:22PM +0100, Bruno Haible wrote: > Rich Felker wrote: > > Testing which of the three allowable signed integer > > representations is used is easy: compare ~(t)1 against and -(t)1 and > > -(t)2. > > Testing which of the three signed intege

Re: bug#7928: mktime test in configure: UB resulting in infinite loop

On Thu, Jan 27, 2011 at 11:42:25PM -0800, Paul Eggert wrote: > On 01/27/2011 02:08 PM, Rich Felker wrote: > > I mean to say that left-shifting a negative value *at all* is > > undefined behavior. I doubt gcc will ever break it, but why not use my > > version of the code that&

Re: bug#7928: mktime test in configure: UB resulting in infinite loop

On Thu, Jan 27, 2011 at 07:42:10PM +0100, Bruno Haible wrote: > Do you mean to say that GCC produces undefined behaviour for shifts of > negative values, even those where the result is negative (no overflow)? > I've never seen a sign of that. I mean to say that left-shifting a negative value *at a

Re: bug#7928: mktime test in configure: UB resulting in infinite loop

On Thu, Jan 27, 2011 at 08:14:56AM -0700, Eric Blake wrote: > # define TYPE_MINIMUM(t) \ > ((t) (! TYPE_SIGNED (t) \ > ? (t) 0 \ > : TYPE_SIGNED_MAGNITUDE (t) \ > ? ~ (t) 0 \ > : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))) > # define TYPE_MAXIMUM(t) \ > ((t) (! TYPE