Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!amdahl!dlb!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c
Subject: Re: strcpy wars, jeez!  A proposed resolution.
Message-ID: <444@goofy.megatest.UUCP>
Date: 8 Apr 88 00:48:10 GMT
References: <4309@ihlpf.ATT.COM>
Organization: Megatest Corporation, San Jose, Ca
Lines: 109

I said I was not going to say any more about the strcpy() thing.

But I would like to make a few comments about *programming*
*philosophy*. 

I DON'T LIKE programming philosophies.  But I guess I have
to admit that I may have one.  Just a little one, mind you.

(BTW. Unless otherwise indicated, my postings contain implicit smilies
 on every line. :-)  :-) :-)  )


in article <4309@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) says:
> 
...

> ...  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().

  Correct!  Do anything reasonable to prevent breaking code.  Even code
  which you consider to be "bad".  As a systems engineer, my job is to
  keep 'em flyin'.  Nothing is more important than that.  When the
  programs fail catastrophicly, the customers don't care that the failure is
  caused by a morally correct change of semantics.

  Here's a case history:  Recently we had to retract a major software
  release from the field.  The problem was that some ten year old
  Berkeley code used a statement similar to the following to skip zero or
  more leading white-space characters:

	if (scanf("%[ \t\n]") == 0) { report_error(); }
  
  Somebody, probably at the company that makes our new workstaions,
  had decided that the string format should have to match
  at least one character in order to succeed.  They duly documented
  said behavior in the man pages.  

  We do extensive QA, but somehow that statement didn't get executed in 
  the QA suites.  BOOM!

  Now, whether or not scanf %[xyz] has to match at least one character
  is, taken by itself, just as silly a consideration as whether strcpy()
  should scan from left to right.  Far too silly to have caused such
  an expensive incident.  The semantics of scanf should never have been
  changed.

  And there was no need to change them.  If you really just HAVE to have
  a new scanf, give it a new name.

  It's easy to make up new names for functions which are similar to old 
  ones.  I once told a fellow programmer, "As long as we can make up new 
  names, we can never be defeated."  I felt real profound about that one.

> 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. 

  Again I agree. Completely.  You're right on the mark.


> 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.
> 
  But, now you're beginning to loose the thread.

  I also like C++, but the notion that the exhaulted gurus can invent
  programming languages to "force" the ignorant masses to produce good 
  code has been discredited again and again.

  (Don't forget the implicit smilies. :-) )

> ...  If you are writing code like this then you
> are becoming very dependent on your particular version/implementation of C.
> 

  I'm not writing the stuff.  There's plenty of it is already written.

>
> Good luck in three years, when your implementation is outdated!
>

  Hey!!  Like, DON'T OUTDATE MY IMPLEMENTATION, dude!

  Did I detect just a hint of an anticipated "told-you-so"?  
  "The transgressors will be punished!"  "Infamy to the implementation-
  dependent rascals!"  

  No?  I guess it's just me.

  I'll respond anyway.  Just pretend for a second that that's what 
  you meant.

  In the first place, people who write shaky code
  are often nice people.  They don't mean to.  They could use some 
  help.  I have no desire to punish them.   They don't need us to pull 
  the rug out from under their code.

  In the second place, it is not only the vile perpetrators who suffer 
  when code breaks.  Often they are long since gone.  But if they are
  not, then you're still on the same team!

  A while back I had to fix some code that my supervisor's supervisor 
  wrote about five years ago.  He's never claimed to be a great programmer.  
  I thought his comment was very funny.   His pronouncement 
  was, "My past has come back to haunt you."