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 observable 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 ... -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
