Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #173804
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Can we lie to memchr? |
| Date | 2023-09-03 19:30 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <87fs3vw1n7.fsf@bsb.me.uk> (permalink) |
| References | <20230903104255.310@kylheku.com> |
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. Well, it does say that "The implementation shall behave as if it reads the characters sequentially and stops as soon as a matching character is found." > For instance, for shits and giggles, memchr could perform a > right-to-left scan, and report the most recently found, hence > leftmost, occurrence of the value. > > Or it could assume it can load an 8 byte word from the start of the object > (even if unaligned), since that lies within 10. Yet that 8 could extend > into an unmapped page. Only if the behaviour is consistent with the above quote, so anything going wrong as a result of looking beyond the first occurrence is, I think, ruled out. -- Ben.
Back to comp.lang.c | Previous | Next — Previous in thread | Find similar
Can we lie to memchr? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 17:59 +0000
Re: Can we lie to memchr? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:22 -0700
Re: Can we lie to memchr? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 18:58 +0000
Re: Can we lie to memchr? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 19:30 +0100
csiph-web