[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DMSFVNUJWKIO.3FQ9T4272UMJC@trevorgross.com>
Date: Wed, 11 Nov 2026 14:08:32 +0000
From: "Trevor Gross" <tg@...vorgross.com>
To: <musl@...ts.openwall.com>, "Trevor Gross" <tg@...vorgross.com>
Subject: Re: Possible out of bounds read in memchr
On Wed Nov 11, 2026 at 7:41 AM CST, Rich Felker wrote:
> [...]
> This is known and intentional. It would be nice if we had a way to
> express the intent, like a variant of the may_alias attribute, but i
> think we'd have to write a load in inline asm to make this formally
> correct. I'm open to changing it, because I don't like having the
> kinds of hacks this is now, but I'm not sure what's best.
I believe assembly or a byte-by-byte search are indeed the only ways.
>From a quick look it appears that glibc and FreeBSD (which uses musl's
implementation) have the same problem. NetBSD and OpenBSD, on the other
hand, are byte-by-byte and thus sound. Seems to be a bit of an
unfortunate decision by the C spec, perhaps there should eventually be a
version that allows reading up to `n` for performance.
LLVM did recently add [1], which presumably could wind up in a Clang
attribute one day. This is what we were looking at using for our mem*
implementations.
- Trevor
[1]: https://llvm.org/docs/LangRef.html#speculative-load-intrinsics
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
