From: Robert Clausecker <firstname.lastname@example.org>
Subject: Re: [musl] strcmp() guarantees and assumptions
Date: Sun, 16 Jul 2023 23:13:14 +0200 [thread overview]
Message-ID: <ZLRdasdXiHLTxKx7@fuz.su> (raw)
Am Sun, Jul 16, 2023 at 09:33:16PM +0200 schrieb Markus Wichmann:
> Am Sun, Jul 16, 2023 at 07:59:57PM +0200 schrieb Robert Clausecker:
> > That's good to hear. Any idea on the “what do existing libc
> > implementations permit” bit?
> So I quickly checked musl, dietlibc, bionic, and glibc, and
> unsurprisingly, all of the implementations I looked at allow the strings
> to be unterminated if they mismatch before access becomes restricted.
> This is, of course, an implementation detail that applications must not
> rely on, but it nevertheless is the case.
> The problem in your implementation is that the calls to strlen() will
> iterate over both input strings to the end, causing basically a cache
> flush for large inputs, only to then iterate over both inputs a second
> time. Iterating only once is a major benefit, since it avoids half of
> the cache misses.
Of course. This was merely a simple example to demonstrate the general
point. I of course do not plan to do anything like that.
> Also, glibc already has an SSE strcmp implementation you may want to
> look at.
I'm not going to look at glibc as it's LGPL licensed. I am aware of the
Intel implementation, but I don't like that it has to duplicate the code
16 times for each possible misalignment pattern. Without having to
ensure that a cacheline of data is only touched once we confirm there
is no previous mismatch, it might be possible to write simpler code, but
I'm currently not entirely sure how.
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments
next prev parent reply other threads:[~2023-07-16 21:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-16 17:22 Robert Clausecker
2023-07-16 17:49 ` NRK
2023-07-16 17:59 ` Robert Clausecker
2023-07-16 19:24 ` Pedro Falcato
2023-07-16 19:29 ` Pedro Falcato
2023-07-16 19:33 ` Markus Wichmann
2023-07-16 21:13 ` Robert Clausecker [this message]
2023-07-17 16:22 ` Adhemerval Zanella Netto
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).