Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: void*
Message-ID: <13530@smoke.BRL.MIL>
Date: 10 Aug 90 20:51:19 GMT
References: <40624@mips.mips.COM> <13499@smoke.BRL.MIL> <18498@rpp386.cactus.org>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 18

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.