This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][AArch64] Add rawmemchr
- From: Alexander Cherepanov <ch3root at openwall dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm 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 20:13:05 +0300
- Subject: Re: [PATCH][AArch64] Add rawmemchr
- Authentication-results: sourceware.org; auth=none
- References: <AM3PR08MB00888F05E81BE0117C6876AB83420 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com> <57502FC8 dot 5040804 at openwall dot com> <5750358A dot 3020809 at arm dot com>
On 2016-06-02 16:32, Szabolcs Nagy wrote:
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?
Because what is in the standard is considered a mistake, because it
hinders the possibilities to catch bugs in user code, or something like
that. Not sure exactly.
The most controversial so far is fread. The kernel will fail the read if
you pass to it a pointer/size that don't fit into user space (e.g.
47-bits on x86-64) so you cannot call fread with the size anywhere close