>So at this point, there's no advantage in doing so. I chose >to do it the way I did because (1) a memchr implementation >would look too much like the GNU (GPL'd) implementation, >(2) to preserve the visible derivation from strlen() as much >as possible, and (3) to avoid an unnecessary added function >call (and perhaps additional variable too). I suppose if >memchr had an optimized version that violated causality >(or at least thermodynamics), strnlen could always be redone >to use it. :-)
Quite. >Ok, but that's not the only function in >/on/usr/src/lib/abi/apptrace/common/interceptlib.c >that goes to extra effort to be safe in the face of a NULL >arg (in contravention to normal practice where the caller >is expected to know better). I don't know whether that's >necessary for the particular use it might be put to, so that's >why I hesitate to suggest that it should be changed to use >a new public strnlen(). I suppose that means I've got to >try and understand how apptrace works... If it's not use,d junk it regardless of how it works. >Well, at least the rest of ON looks strnlen-free. :-) >I suppose for the sfw folks, that's their problem? Yes. If there are strnlen()s there and they will be replaced by some configure run, it's perhaps a good idea to check whether the semantics are exactly the same (specifically in the light of NULL) Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
