Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: strcpy wars, jeez! A proposed resolution. Message-ID: <4215@ihlpf.ATT.COM> Date: 31 Mar 88 01:13:21 GMT References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <7506@brl-smoke.ARPA> <4251@hoptoad.uucp> <6286@dhw68k.cts.com> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 26 In article <6286@dhw68k.cts.com> david@dhw68k.cts.com (David H. Wolfskill) writes: >The current dpANS also specifies "If copying takes place between objects >that overlap, the behavior is undefined." I would feel rather more >comfortable with changing that to read "... implementation defined." I would not! This would imply that a program which calls strcpy() with overlapping strings is 'correct', and this is simply not true. Remember, implementation-defined behavior means (quoted from the draft section 1.6--Definitions of Terms): "behavior, for a correct program construct and correct data, that depends on the characteristics of the implementation and that each implementation shall document." If you have overlapping strings you have incorrect data. If this were to change (something which I am against), all programs that use strcpy() would be suspect every time a new version of the compiler comes out (especially since many compilers use inline assembly instead of doing a function call for strcpy()). This is not something which should depend on the implementation. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_