On Aug 30, 2:51pm, m.droch...@fz-juelich.de (<m.droch...@fz-juelich.de>) 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