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_SIGNED
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
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's 100% safe and never invokes
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 integer representations is in use
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
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! How about
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-seekable input.
Thanks, that's better
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
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 and most other
POSIXish hosts
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 useful, and how to avoid the need
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 reading until error, and count the bytes read
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
least a 10% speedup in operation. It _really is_
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 these as
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 corner
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
undefined behavior (accessing an object
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
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 whether
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:
http://sourceware.org/bugzilla/show_bug.cgi?id=4586
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 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
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
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
On Mon, Jun 18, 2012 at 10:21:34AM -0700, Ben Pfaff wrote:
Bruno Haible br...@clisp.org 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
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 and the source of
all the complexity
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/Testing/Gnulib,
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 of
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/Testing/Gnulib,
that explains how to use gnulib
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, as I
discussed on the musl list, I think it's bad
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
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:
Yes, they also recommend invoking extremely serious UB (aliasing
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-gcc
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 stdio.h
#include errno.h
int main()
{
int ret;
int err;
ret = printf (%.500f,
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
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,
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.
On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote:
[CCing the musl list]
Isaac Dunham wrote in
http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00101.html:
musl is designed for standards conformance,
There is a recipe, in http://sourceware.org/glibc/wiki/Testing/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 directory name, and the kernel
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
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. Modify gl_FUNC_FFLUSH_STDIN so that it checks
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
support future broken systems.
But we're
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
things as well. I pushed
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 need
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
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
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"
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
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.
> >
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 should f
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
48 matches
Mail list logo
