Path: utzoo!mnetor!uunet!husc6!mailrus!ames!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: strcpy Message-ID: <4190@ihlpf.ATT.COM> Date: 30 Mar 88 00:19:38 GMT References: <793@cresswell.quintus.UUCP> <545@anuck.UUCP> <810@cresswell.quintus.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 43 In article <810@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > >> The moral of this is, don't depend on bizarre side effects unless > >The order in which strcpy works is hardly a "bizarre side effect". I'm sorry, but it is! If you are writing code which is dependent upon the IMPLEMENTATION of strcpy instead of the DESCRIPTION of strcpy, then you ARE depending on side effects of strcpy. Whenever possible, code should NOT depend on the side effects/implementation details of a function that it calls. Suppose I looked at the source for some obscure system call (call it foo) and found out that it modified a static variable somewhere in memory. Would you say that it is okay for me to look at the variable that it modified (assuming that this was not a documented property of foo, of course)? I think not. The strcpy argument is no different. This is one of the things that makes code very hard to maintain. For example: one of the routines that I was using returned a unique number according to a certain set of constraints. It also happened that the number it returned was pseudo-random (it would not necessarily return the same number under similar circumstances), but this was a property of the implementation, not the description of the routine. I modified the routine so that it always returned the lowest number that met the constraints (changed the implementation, not the description). Guess what happened? Another part of the program was in an infinite loop because it called this routine to generate two separate numbers which met the constraints, but my (new) routine always returned the same number. Now I know why people don't like to touch code that already works (old code is just too delicately intertwined). With languages such as C++ becoming more popular, abstraction will be forced so that these types of problems do not occur. But until the time that this is commonplace, we should be trying to abstract on a procedural level. By this I mean that code, whenever possible, should be written so that it depends ONLY upon the description of a subroutine and NOT dependent on the implementation of that subroutine. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_