This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][AArch64] Add rawmemchr
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Alexander Cherepanov <ch3root at openwall dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, 'GNU C Library' <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>
- Date: Thu, 2 Jun 2016 14:32:58 +0100
- Subject: Re: [PATCH][AArch64] Add rawmemchr
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <AM3PR08MB00888F05E81BE0117C6876AB83420 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com> <57502FC8 dot 5040804 at openwall dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 02/06/16 14:08, Alexander Cherepanov wrote:
> On 2016-05-27 16:29, Wilco Dijkstra wrote:
>> Add a simple rawmemchr implementation. Use strlen for rawmemchr(s, '\0') as
>> it is the fastest way to search for '\0'. Otherwise use memchr with an infinite size.
>> This is 3x faster on benchtests for large sizes.
>
> Is memchr on your arch guaranteed to work with an infinite size?
>
> In theory, it's guaranteed by C11 and POSIX (e.g. see http://open-std.org/jtc1/sc22/wg14/www/docs/n1533.htm )
> but IIUC there is a sentiment in the glibc community that passing to a library function a size greater than the
> real size of an object is an error. (Would be glad to find out I misunderstood something here.)
>
why would the glibc community want something that's in
conflict with the standard?
an implementation can turn ub into defined behaviour,
but not the other way.
> In practice, memchr with an infinite size is broken at least on x86-64 and i386 --
> https://sourceware.org/bugzilla/show_bug.cgi?id=19387 .
>