[email protected] wrote:
> >Previous versions of the POSIX standard made no limitations on strcpy()
> >but the current standard claims that using strcpy() with overlapping
> >buffers gives undefined results.
>
> Even the Single UNIX ? Specification, Version 2, says:
>
> If copying takes place between objects that overlap, the behaviour
> is undefined.
I cannot check again ad opengroup.org is down since at least 2 hours.
I remember however, that I did not see such hint in SUSv3.
> >Most existing programs have been written before the standard was changed
> >and I know of a lot of places where strcpy() is called with overlapping
> >buffers
> >in order to e.g. deal with escaped strings.
>
> I understand what you mean. Clearly the standard says that this is
> undefined but the practice that it works when copying overlapped strings
> in such a way that a naive implementation would get it right.
>
>
> I've not seen the issue and a short example would be nice to see.
I just checked 500 calls to strcpy() (including the oldest program I am aware
of - sccs). There is a overlap case in lndir.c from Xort and there is
a case in my libxtermcap/tgetent.c:
LOCAL void
tstrip()
{
register char *bp = tbuf;
register char *p;
if (bp == NULL)
return;
#if defined(TIOCGSIZE) || defined(TIOCGWINSZ)
tdeldup("li");
tdeldup("co");
#endif
while (*bp) {
if (*bp++ == ':') {
if (*bp == ':' || *bp == ' ' || *bp == '\t') {
p = bp;
while (*p)
if (*p++ == ':')
break;
strcpy(bp--, p);
}
}
}
}
BTW: I would guess it only happens when the overlap is less than 8 chars
and I believe that new behavior may be a result of the upgraded compiler
Sun uses.
Jörg
--
EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
[email protected] (uni)
[email protected] (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
