strcpy

[00704a-Liber]

In article <810 at cresswell.quintus.UUCP> ok at 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."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah