Eric Blake wrote:
> Yes; I've done that as follows, and also added memchr as a dependency for
> vasnprintf (the only module that used memchr but did not depend on it).
Good, thanks. I do the same for the other modules that also use vasnprintf.c:
2009-06-08 Bruno Haible
* modules/unis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/31/2009 7:08 AM:
>> But as there are systems in the wild with the broken implementation, we
>> should probably start worrying about replacing the buggy memchr
>> implementations.
>
> As a first step, let me add a test to
Eric Blake wrote:
According to Matthew Woehlke on 5/29/2009 6:19 PM:
the replacement will be C code that scans an aligned word at a
time, similar to how it is already done in memchr2.c. Not quite as
efficient as hand-tuned assembly, but hands down faster than a byte at
a time.
...but the origi
Bruno Haible wrote:
> Eric Blake wrote:
>> > I don't think it is a bug. memchr could also be implemented by doing
>> > a backwards search and still be conforming to ISO C99 and POSIX:
>>
>> The Austin Group disagrees with you. Here is the results from the meeting
>> yesterday
>> (https://www.openg
Eric Blake wrote:
> > I don't think it is a bug. memchr could also be implemented by doing
> > a backwards search and still be conforming to ISO C99 and POSIX:
>
> The Austin Group disagrees with you. Here is the results from the meeting
> yesterday
> (https://www.opengroup.org/sophocles/show_mai
Eric Blake wrote:
...
> It looks like the problems with glibc memchr on x86_64 are
> present in glibc 2.10, but fixed in git:
> http://sourceware.org/bugzilla/show_bug.cgi?id=10162
>
> But as there are systems in the wild with the broken implementation, we
> should probably start worrying about rep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 5/29/2009 6:19 PM:
>> the replacement will be C code that scans an aligned word at a
>> time, similar to how it is already done in memchr2.c. Not quite as
>> efficient as hand-tuned assembly, but hands down faster than
Eric Blake wrote:
According to Matthew Woehlke on 5/29/2009 4:59 PM:
Add to DESCRIPTION
Implementations shall behave as if they read the memory byte by byte
from the beginning of the bytes pointed to by s and stop at the first
occurrence of c.
Doesn't that preclude *any* sort of optimization? O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 5/29/2009 4:59 PM:
>>> Add to DESCRIPTION
>>> Implementations shall behave as if they read the memory byte by byte
>>> from the beginning of the bytes pointed to by s and stop at the first
>>> occurrence of c.
>
> Doesn
Eric Blake wrote:
According to Bruno Haible on 5/26/2009 4:05 PM:
Eric Blake wrote:
http://www.alphalinux.org/archives/axp-list/March2001/0337.shtml
It looks like the bug is alpha-specific in memchr
I don't think it is a bug. memchr could also be implemented by doing
a backwards search and st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/26/2009 4:05 PM:
> Eric Blake wrote:
>> http://www.alphalinux.org/archives/axp-list/March2001/0337.shtml
>>
>> It looks like the bug is alpha-specific in memchr
>
> I don't think it is a bug. memchr could also be impleme
11 matches
Mail list logo