> Your buffers are probably overlapping. Try using bcopy instead.
Or "memmove()" - from the ANSI C spec:
4.11.2.1 The "memcpy" function
...
Description
... If copying takes place between objects that overlap,
the behavior is undefined.
...
4.11.2.2 The "memmove" function
...Copying takes place as if the "n" characters from the
object pointed to by "s2" are first copied into a temporary
array of "n" characters that does not overlap the objects
pointed to by "s1" and "s2", and then the "n" characters from
the temporary array are copied into the object pointed to by
"s1".
"As if" means "this isn't necessarily the way it's actually
implemented", so "memmove", in practice, probably doesn't allocate that
temporary array and do two copies.
However, in this particular case, given the call:
> > I've been getting a bus error when I use memcpy to copy some stuff into
> > a structure out of the packet buffer:
> >
> > memcpy((void *)&haadr, (void *)dp, sizeof(haadr));
I suspect the problem isn't an overlap problem - and I suspect that in
those cases where "memcpy()" doesn't nicely handle overlapped copying,
the symptoms are that it trashes what it's copying as it copies it, not
that you get a bus error.
>From the symptoms, from the fact that adding "-fno-builtin" made the
problem go away, and from the fact that the original poster works for a
company whose products use a processor that faults on unaligned
accesses, and an OS that reports unaligned access faults as bus errors,
I suspect the problem may be that GCC 2.95.2 may be generating
insufficiently paranoid code, and that it's doing "ldd"/"std" pairs or
something evil such as that.
It might be interesting to look at the core dump, and dissassemble the
offending code, to see whether that's what it's doing and, if so, see if
a small test case can be made to reproduce the problem, and either send
the bug report to the GCC maintainers or, for the sufficiently
ambitious, try to track down the source of the bug and send that to the
GCC maintainers as well.
