From: Nix <nix_at_esperi.org.uk>
Date: Sun, 04 Jan 2004 17:51:59 +0000

On Sun, 28 Dec 2003, phil_at_carangg.de stated:
> Funny. When you program a plugin you cannot initialize a string with
>
> char mystring[] = "mystring";
>
> because inernally it seems to use memcpy.

Yes, under some circumstances: see e.g. gcc/expr.c:store_expr(),
gcc/expr.c:emit_block_move(), emit_block_move_via_libcall(), and
emit_block_move_libcall_fn(). The latter spits out a libcall to memcpy()
or bcopy().

See <http://gcc.gnu.org/PR4417>, and the Standards node in the GCC
manual, which states (as of GCC 3.3.1, but this requirement hasn't
changed for years, just become better-documented):

,----
| GCC requires the
| freestanding environment provide `memcpy', `memmove', `memset' and
| `memcmp'. Some older ports of GCC are configured to use the BSD
| `bcopy', `bzero' and `bcmp' functions instead, but this is deprecated
| for new ports. Finally, if `__builtin_trap' is used, and the target
| does not implement the `trap' pattern, then GCC will emit a call to
| `abort'.
`----

(The sh GCC targets do not emit calls to bcopy(), bzero(), or bcmp().)

> But that function is only
> available via the api pointer. Is that fixable / worth fixing?

You fix it by implementing memcpy(). It's only a few bytes... :)

-- 
As they say, build a better mousetrap and the world will beat a
path to your door. But nobody ever got anywhere outlawing mice.

Received on 2004-01-04