Microtec Compiler MCC68K and memcpy

Hello,

I have a problem with the Microtec Compiler MCC68K.
We have written our own memcpy() function due to safety reasons. But
even with all optimizations turned off the MCC68K replaces a function
call to memcpy() with several lines of assembler code during the
compilation stage. The linker will never see an unresolved symbol like
_memcpy.
Has anyone an idea how we can force the compiler to use our own
function ?

Thanks
Karl-Heinz

On Wed, 04 May 2005 01:49:23 -0700, Karl-Heinz wrote:

> Hello,
> 
> I have a problem with the Microtec Compiler MCC68K.
> We have written our own memcpy() function due to safety reasons. But
> even with all optimizations turned off the MCC68K replaces a function
> call to memcpy() with several lines of assembler code during the
> compilation stage. The linker will never see an unresolved symbol like
> _memcpy.
> Has anyone an idea how we can force the compiler to use our own
> function ?
> 
> Thanks
> Karl-Heinz

Of curiosity, what "safety reasons" made you write your own memcpy() ?  If
you want to replace standard library calls with your own versions (so that
you know for sure exactly what code is running), you would probably be
better off using new names for the functions and avoiding the standard
ones.

There may be specific compiler options to control the use of "intrinsic"
functions like this - compilers often optomise memcpy() and other 
library functions (such as abs() ) because the code is very much more
efficient when inlined.  If you want to force it to use your own function
and can't find switches to do this, perhaps you could do something like:
	#define memcpy(dest, src, num) Memcpy(dest, src, num)
where Memcpy() is your own version.

"Karl-Heinz" <karl-heinz.rossmann@liebherr.com> wrote in message
news:1115196563.508313.66340@f14g2000cwb.googlegroups.com...
> Hello,
>
> I have a problem with the Microtec Compiler MCC68K.
> We have written our own memcpy() function due to safety reasons. But
> even with all optimizations turned off the MCC68K replaces a function
> call to memcpy() with several lines of assembler code during the
> compilation stage. The linker will never see an unresolved symbol like
> _memcpy.
> Has anyone an idea how we can force the compiler to use our own
> function ?
>
> Thanks
> Karl-Heinz
>

Global search and replace all occurrences of memcopy with safecopy.

Cheers,
Alf

Karl-Heinz wrote:
> 
> I have a problem with the Microtec Compiler MCC68K.
> We have written our own memcpy() function due to safety reasons. But
> even with all optimizations turned off the MCC68K replaces a function
> call to memcpy() with several lines of assembler code during the
> compilation stage. The linker will never see an unresolved symbol like
> _memcpy.
> Has anyone an idea how we can force the compiler to use our own
> function ?

Use a different name.  It is already undefined behaviour for you to
use the memcpy name in your own source - that is reserved for the
implementation.  See the C standard.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Unbeliever wrote:
> "Karl-Heinz" <karl-heinz.rossmann@liebherr.com> wrote in message
> news:1115196563.508313.66340@f14g2000cwb.googlegroups.com...
> > ...
> > Has anyone an idea how we can force the compiler to use our own
> > function ?
>
> Global search and replace all occurrences of memcopy with safecopy.

Or, if you prefer not to change call sites, use a macro.

--Toby

> 
> Cheers,
> Alf

Karl-Heinz wrote:
> Hello,
> 
> I have a problem with the Microtec Compiler MCC68K.
> We have written our own memcpy() function due to safety reasons. But
> even with all optimizations turned off the MCC68K replaces a function
> call to memcpy() with several lines of assembler code during the
> compilation stage. The linker will never see an unresolved symbol like
> _memcpy.
> Has anyone an idea how we can force the compiler to use our own
> function ?
> 
> Thanks
> Karl-Heinz
> 

Give it another name.