Date: Sat, 03 Jan 2015 22:48:15 +0000 From: Howard Chu hyc@symas.com To: kurt@OpenLDAP.org, openldap-its@OpenLDAP.org Subject: Re: (ITS#8015) memcpy() overlapping in many places

kurt@OpenLDAP.org wrote:

...

AC_MEMCPY is generally memove(3). It would only be memcpy(3) if both = memmove(3) or bcopy(3) were not available. So at most your patch will = cause link errors.

Closing this ITS. The patch is obviously invalid.

I decided after all to answer regarding AC_MEMCPY as this illustrative case mess of the source code (aka rebus code style). In my opinion it also illustrates the substitution of concepts in conversations about the quality of code and demonstrates the incorrect use of tools such as autconf.

If we look at the source code, you will see that there are three things that are relevant to the discussion:directly memmove(), directly memcpy() and macro AC_MEMCPY. Simultaneous use directly memcpy() and AC_MEMCPY seems like a legacy effort for compatibility. Ok, this is not a problem, just a less of changes.

But in fact AC_MEMCPY used for overlapped source and destination, like a memmove(). Ok, as you noted, the AC_MEMCPY macro will be expanded to memmove(), therefore it is no problems with overlapped source and destination. But then, why macro is really named as 'MEMCPY'?

However AC_MEMCPY will be _silently_ expanded to memcpy() if no memmove() or bcopy() is available!

What we have at the end? - Completely unnecessary macro which is confusing because of the inappropriate name. - The possibility of incorrect and quiet substitution macro that will lead to a wonderful unexpected errors. - Misuse autoconf, which leads to the creation of compatibility issues, rather than overcome them. This sort of thing I call "rebus code style" ;)

Leonid.