🚀 go-pugleaf

In article <18498@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:
>In article <13499@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>>In article <40624@mips.mips.COM> sah@mips.COM (Steve Hanson) writes:
>>>however the inc/dec cause a temporary variable to be introduced:
>>That could be avoided by defining the function as
>>	void *memchr(const char *s, int c, unsigned int n)
>>which works because of the "same representation" requirement.
>Doesn't this defeat the purpose of (void *) as an abstraction
>mechanism?

Well, we were talking about a piece of the implementation, not a normal
application (for which one could define the interface differently).
In actuality, I expect most implementations of functions like this
would be written in assembly language, not because C doesn't obtain a
good result, but because customers are perceived as clamoring for the
highest possible speed (in benchmarks, etc.), so it is deemed desirable
from a marketing viewpoint.  If you don't demand that the C version be
utterly optimal, there is no need for the kludge I suggested.