Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!apollo!blodgett
From: blodgett@apollo.HP.COM (Bruce Blodgett)
Newsgroups: comp.std.c
Subject: Re: memcpy
Message-ID: <4cedc58d.20b6d@apollo.HP.COM>
Date: 20 Sep 90 22:21:00 GMT
References: <1990Sep19.021418.11574@maths.tcd.ie>
Sender: root@apollo.HP.COM
Lines: 24
In-reply-to: tim@maths.tcd.ie's message of 19 Sep 90 02:14 GMT


In article <1990Sep19.021418.11574@maths.tcd.ie>, tim@maths.tcd.ie
(Timothy Murphy) wrote:
> In unzip.c it is assumed that the effect of
> 	buf[0] = c;
> 	memcpy(buf+1, buf, 20);
> is to set
> 	buf[0] = buf[1] = buf[2] = ... = buf[21] = c.
...
> Is this a bug on the Sparc,
> or is memcpy not fully specified?

According to the ANS C standard, section 4.11.2.1, "If copying takes
place between objects that overlap, the behavior is undefined."  Thus
whatever a C compiler wants to do is "correct" in this case.

By the way, why don't you use the much safer standard function:
    memset(buf, c, 21);
which sets buf[0] = buf[1] = buf[2] = ... = buf[20] = c.
If you want buf[21] == c (which is NOT what your original code does),
make the 3rd argument 22 rather than 21.
Bruce Blodgett
blodgett@apollo.hp.com
(508) 256-0176 x4037