bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why require SLOW_BUT_NO_HACKS for stubs?


From: Isaac Dunham
Subject: Re: Why require SLOW_BUT_NO_HACKS for stubs?
Date: Mon, 11 Jun 2012 18:22:02 -0700

On Sun, 10 Jun 2012 19:00:54 -0700
Paul Eggert <address@hidden> wrote:

> On 06/09/2012 11:05 PM, Isaac Dunham wrote:
> > Is there any reason not to merge
> 
> Performance, surely.  But if there's
> consensus that performance does not matter that
> much with musl, perhaps we should default to the
> slow version with musl.
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."
All supported platforms are unaffected.
> Is there any simple way to tell at compile-time,
> or at configure-time, that musl is being used?
> That would help us distinguish musl (where being
> slow is acceptable) from other platforms (which may not
> want that).
First, the proposal is "Run slow anywhere current code would #error",
not "default to slow code".
Second, officially, no. musl is designed for standards conformance,
and the maintainer takes the perspective that #ifdef should be reserved
for non-standard-conformant libc versions.
Unofficially, I can think of a few oddities:
strl* are supported with -D_BSD_SOURCE, while __linux__ will be defined;
almost all symbols use the function name; only SUSv4 is supported with
_XOPEN_SOURCE (so -D_XOPEN_SOURCE=600 with <unistd.h> still gives
_XOPEN_VERSION=700).
None of these are guaranteed to stay the same, though no _XOPEN_VERSION
less than 700 is likely to be supported.

Isaac Dunham




reply via email to

[Prev in Thread] Current Thread [Next in Thread]