Re: CVS commit: src

On Aug 30, 2:51pm, M.Drochner%fz-juelich.de@localhost
(<M.Drochner%fz-juelich.de@localhost>) wrote:
-- Subject: Re: CVS commit: src
| memset() and memcmp()'s semantics both don't fit too well:
| The former forces to carry that mostly useless fill pattern argument around,
| which could be in the way of optimization.
I am not sure I would call it useless. 0's are NULL's and sometime you want
all 1's to get core-dumps (or 0xa5's) to notice overwrites. Also the point
of this is not performance... Most modern code uses memset() anyway, and
if the second argument is not zero, you are not going to have a drop-in
replacement. While memset can implement bzero, the converse does not hold.
| memcmp() promises to be usable for alphabetical sorting which would make
| a constant-time algorithm needlessly complicated and is not of use for
| the intended applications.
memcmp() does not promise alphabetical sorting. It just promises to do the
byte comparison as unsigned so that the results are consistent. It is not
complicated to do this at all, for example:
int
consttime_memcmp(const void *s1, const void *s2, size_t n)
{
int rv = 0, sv = 0;
const unsigned char *p1 = s1, *p2 = s2;
do
if (rv == 0)
rv = *p1++ - *p2++;
else
sv = *p1++ - *p2++;
while (--n != 0);
return rv ? rv : (sv - sv);
}
Again most code uses memcmp, and if you find an application that actually
uses the result, you should be providing the correct result. Otherwise you
will need to implement something like I did.
bcmp() only promises return 0 if equal, non-zero if not.
Again what we see is that the mem*() functions can implement the b*() functions
unambiguously, where the converse does not hold. Also most of the world uses
mem*() not b*(), so you are going to be changing semantics if you convert
existing code to the new functions. What I propose here is the safest way
to implement this that does not require too much thinking at each conversion.
I think we should let others chime in.
[and of course there is bcopy and ovbcopy and memcpy and memmove, and the
opposite order of the arguments, but fortunately we have no reason to replace
those yet]
christos