Re: (ITS#8015) memcpy() overlapping in many places

[leo@yuriev.ru]

> *
> 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.