Re: Solving the recursive memcpy/memset/etc. issue

[Rich Felker <dalias@aerifal.cx>]

On Thu, Aug 01, 2013 at 10:26:55AM +0200, Jens Gustedt wrote:
> Am Donnerstag, den 01.08.2013, 10:03 +0200 schrieb Luca Barbato:
> > > Well, it would be an ugly heuristic like running cc -S -o - on 
> > > src/string/memcpy.c, with -Dmemcpy=noname or something, and grepping 
> > > the output for memcpy...
> > 
> > Indeed.
> 
> there might be the word memcpy in comments or whatever, depends on the
> assembler format etc. might be really relatively difficult to set up
> reliably.

Well as long as they're false-positives for detecting the bug rather
than false-negatives, at worst you'd get a slow memcpy rather than a
crashing libc.

>  - compile it with that -Dmemcpy=noname trick to a normal .o and use
>    nm to look for an undefined symbol "memcpy".

Using nm is undesirable with respect to cross-compiling. It requires
detecting the right version of nm to run, which may be hard; I don't
even have *-linux-musl-nm in my path on my laptop here, just the gcc.
Right now cross-compiling is as simple as setting CC to the cross
compiler, and I don't want to break that.

>  - use a different name for the implementation of the function from
>    the start, __musl_memcpy or so. Then you could do the check for the
>    memcpy symbol on the normally compiled .o and (if everything is ok)
>    rename the __musl_memcpy to memcpy with some linker trick.

This is a lot more ugliness in the build system and I'm not clear on
the benefit over the above methods.

>  - put "#define memcpy __musl_memcpy" at the start of string.h
>    if __musl_memcpy would refer to memcpy this would give an link time
>    error for an undefined symbol.

No linking is done to make libc.a. As for linking applications, the
symbol memcpy must exist. You are always permitted to remove macro
definitions and refer to the underlying function. Even if this were
valid, it would change the ABI in a very ugly hackish way that belongs
in glibc, not musl.

Rich