> Richard L. Hamilton wrote: > > I did some tests to check for looking past the end. > They aren't perfect, because they > require that the area in which it may be ok to look > _ends_ at a page boundary > (so the next page can have no permissions such that > accessing it would > cause an obvious memory violation). So they don't > cover the case where the > area to be searched ends other than on word > boundaries. (But they work fine > with cases where it doesn't start on a word > alignment.) > There can't be many cases where the distinction > matters, can there? > Reading extra bytes that are within the same word or > at least on the > same page should be safe as long as you're reading > from ordinary memory > and not a memory-mapped device with side-effects. > There are no > bservable effects from such internal behavior. > > I suspect that passing the address of a memory-mapped > device with such > operational constraints to strnlen() or similar > library function would > be a "bad idea" in any portable software. So long as > the right result > is obtained based on the documented interface, it > doesn't matter whether > an implementation reads every byte in forward or > backwards order or > perhaps does something entirely different. And for > hardware, order (as > well as extent) often matters greatly. > > If you care about side-effects, stick to the > straight-and-narrow path: > use "volatile" where required (strnlen doesn't treat > the argument that > way) and code exactly what you mean. These cases are > darned rare in > practice, so it doesn't seem like a high bar to > reach. > > The trade-off here would be between providing a > well-performing > implementation that perhaps reads but does not > "examine" (i.e., include > in the final length computation) bytes past the 'n' > limit, and one that > performs much less well, but strictly interprets the > word "examine" to > mean "load into a machine register even if never > compared." You can't > have everything ...
Right - I can't see it mattering either except when accessing memory-mapped hardware (that had control registers rather than actual memory like say video memory), which I have difficulty imagining it being useful to use memchr() against anyway. In fact, if memory accesses all actually take place in terms of whole words (given the bus width, and with any unwanted portion perhaps just tossed), I'm not sure it would be detectably different even then. Short of an instruction-level trace (which would be as hard to read as the assembler implementations of memchr()), I'm not sure I see any way at all to tell if it _might_ be looking at too many bytes within the last word. As I recall, it was intentional to use memchr() precisely because it would give strnlen() the benefit of the optimizations already applied to memchr(), without creating more assembler code to maintain. And to top it all off, I just found an email from Jörg dated 5 October 2006 _recommending_ the use of memchr() to implement strnlen(). :-) -- This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
