Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Can we lie to memchr? Date: Sun, 03 Sep 2023 11:22:10 -0700 Organization: A noiseless patient Spider Lines: 21 Message-ID: <86r0nfqfql.fsf@linuxsc.com> References: <20230903104255.310@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="6ef63087f855104b64afdd13e03f4862"; logging-data="1088572"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19enkUAjIn5U+J7zBOx2avMZsQK3IAVjEE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:0ksHIjZDU19hJXdUpAr21hWGj5I= sha1:Y1LxhvarL4u7WjrVILs6Z9WJ6Ew= Xref: csiph.com comp.lang.c:173803 Kaz Kylheku <864-117-4973@kylheku.com> writes: > You would think that memchr can be used to test whether a string is > longer than N without traversing it. For instance we can take a > gigabyte-long character string and efficiently test wheether it is > shorter than 10 characters: > > memchr(gigastr, 0, 10) == 0 > > if a null is found within the first 10 bytes, then its length > is 10 or more. > > But suppose a 7 byte string is passed (length 6). > > That *object* is smaller than n; it does not have an "initial sequence > of n characters" for memchr to search. > > ISO C doesn't say that bytes of the initial sequence which are > beyond are sought-after value shall not be accessed by memchr. [...] It does, and has for more than 10 years.