Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Implementation-DEPENDENT code (was:strcpy) Message-ID: <4331@ihlpf.ATT.COM> Date: 8 Apr 88 01:02:26 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> <4309@ihlpf.ATT.COM> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 90 The reason that I do not like the proposed change (on the net, that is) to strcpy() is because it ENCOURAGES implementation-dependent code, which, to put it simply, is a *bad* programming paradigm. We should be abstracting on at least a procedural level, if not higher. If we can do that, then code maintenence becomes easier, integrating new code becomes easier and programming in general becomes easier. Programming projects these days are simply getting too big to be able to just 'hack' together something that works. One of the arguments for the change is "I have some code now which relies on the fact that strcpy() is left-to-right." Since this code does not conform to C as it is defined now, I don't think ANSI should say "that's ok. We will change the language so that your BAD code becomes GOOD code." (BTW, I do not want to infer that the committee IS saying this; I am just trying to make a point.) And if this gets 'fixed' (like a cat gets fixed--no smiley), then shouldn't all the bad programming practices get 'fixed', too. Take the following code segment for example: #include int main() { int i=1; while (i < 10) { int j; if (1 == i) j = 2; printf("%d ", j); j += 2; i++; } } On every implementation of C that I tried this on, it printed out 2 4 6 8 10 12 14 16 18 Now, a few questions about this program. Assuming that this program is designed to print out the even numbers from 2 to 18 inclusive, is this a *correct* implementation of that algorithm, given the definition of C? NO!! Why not?? (Think about it before peeking ahead) The reason is that j is declared inside a block, and this block is entered and exited through each iteration of the while loop. [Note: if this block was not entered and exited through each iteration, then changing 'int j;' to 'int j=2;' should not change my output. But it does change it to "2 2 2 2 2 2 2 2 2 ". If you still don't believe it's a block, then put an extra set of braces around everything from 'int j=2' until just before but not including 'i++;'. You still get the same results, and the points I am about to make still hold.] As K&R 1 says on page 198: "... automatic and register variables which are not initialized are guaranteed to start off as garbage." This means that every time through the loop, j should start off as garbage (and I can construct a slightly different case that would make j garbage on some implementations) and NOT (necessarily) contain it's previous value. Now, because I also know a little about how C is implemented, I know why I got even numbers instead of junk. In a nutshell, it is because the actual space for j is never reallocated (there is a lot more to this, but this is not the issue). However, there is nothing within C which guarantees that this space is not reallocated. SO, I repeat: is this an example of acceptable code?? NO!! Is this type of construct in use today? (Unfortunately) YES!! (and not just in old code which nobody ever looks at, either.) Is this bad code? YES! Should C be 'fixed' so that this bad code becomes *good* code? NO!!! Fix the bad programs; don't change the language so that these bad programs become acceptable! Our programming languages should encourage us to use good programming methods. The proposed change to strcpy() discourages abstraction on a procedural level, and having 'tightly coupled' code where it is not needed is simply bad programming. We should be trying to stay away from locking into one specific way of implementation, since no one knows what discoveries the future might hold. Now is the time to fix up all the *bad* C programs; after ANSI C is passed, we probably won't get another chance. The proposed change to strcpy() will have far reaching consequences which many people simply aren't thinking through. [Sorry to have been so philosophical about it, but isn't that what the argument is all about?] -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_