Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!mailrus!tut.cis.ohio-state.edu!osu-cis!att-cb!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: <4309@ihlpf.ATT.COM> Date: 7 Apr 88 00:39:11 GMT References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <7506@brl-smoke.ARPA> <4251@hoptoad.uucp> <6286@dhw68k.cts.com> <4215@ihlpf.ATT.COM> <6476@dhw68k.cts.com> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 47 In article <6476@dhw68k.cts.com> david@dhw68k.cts.com (David H. Wolfskill) writes: >In article <4215@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >>In article <6286@dhw68k.cts.com> David Wolfskill wrote: >>>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." > >>If you have overlapping strings you have incorrect data. > >Well, thank you for your opinion; however, I respectfully disagree. >Given an order in which the copying shall be done, the operation of >copying data from one string to another (when the two strings have a >known degree of overlap) can be a well-defined one. Oh, so you want the copying of two strings to be WELL-DEFINED, not implementation-defined or undefined. Why did you beat around the bush for so long?? I do agree that if you know the algorithm, all the side effects are well-defined. I just do not agree that you, the non-kernel applications programmer, should have to write code that is dependent on the *implementation* of a system call. This only leads to nightmares for code maintenance people (which is part of my job). For example: some of the people right now who are arguing for strcpy() to be *defined* as left-to-right string copy are bringing up the point that code currently being used is dependent on this implementation of strcpy(). They are claiming that it is hard to maintain since it is implementation-dependent. We should be going away from code like this, not towards it. This is one of the reasons I like C++, because it forces programmers to code without knowing the implementations of their objects/classes. If the implementation of a class is changed, the rest of the code doesn't break. >It is quite possible -- and to me, reasonable -- to define an algorithm >in such a way that it uses the implementation-defined behavior of such >an operation. You are right in one sense: it is quite possible to define an algorithm in such a way that it uses the *side effects* (aka, implementation-defined behavior) of such an operation. If you are writing code like this then you are becoming very dependent on your particular version/implementation of C. Good luck in three years, when your implementation is outdated! -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_