Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!rbbb@rice.ARPA
From: rbbb@rice.ARPA (David Chase)
Newsgroups: net.lang.c
Subject: Bozos
Message-ID: <9194@brl-tgr.ARPA>
Date: Wed, 13-Mar-85 17:05:04 EST
Article-I.D.: brl-tgr.9194
Posted: Wed Mar 13 17:05:04 1985
Date-Received: Fri, 15-Mar-85 00:40:02 EST
Sender: news@brl-tgr.ARPA
Lines: 42

You people are crazed! TEN messages on string copying idioms in 5 days,
all saying about the same inane useless thing.

My stupid comments:

1) Of course it is better to use strcpy than to write it again and again
   yourself, and of course is more readable and right the first time.
   Of course, the piss-poor implementations of the standard library
   encourage recoding of library routines.
2) We run 4.2, and strcpy is NOT written in assembler.  Bcopy and friends
   are written in assembler.
3) The DECUS C library version works only for strings smaller than 65k, but
   will work correctly when source and destination are overlapping
   (because movc3 works that way), unlike most implementations of strcpy
   that I have seen.  Crappy library routines NOT written efficiently NOT
   written in a general way lead to private recodings of library routines.
4) Strlen followed by strncpy is not faster than strcpy because strncpy is
   defined to copy up to the null OR the nth character, whichever comes first.
   Perhaps you might try strlen followed by bcopy.
5) Register variables are a hopeless hack advertised as a feature by
   lazy-ass compiler writers.  Even when I DO know which variables are
   more frequently used, I cannot achieve the same results as a worthwhile
   compiler that places a variable in a register only when it really needs
   to be there, and then (GASP!) puts SOMETHING ELSE in that same register.

Before flaming at me that "the same code isn't efficient everywhere" and
similar mindless drivel, perhaps you might consider the existence of TWO
VERSIONS, one portable and exhibiting the defined behavior, the other
written for a specific machine to run as fast as it possibly can (and ALSO
exhibiting the defined behavior).  There are lots and lots of companies
out there selling Unix, and they can only gain by coding efficient
machine-specific versions of library routines, because that will make
their products run faster (and since the improvements are non-portable, no
one else can pirate them, right?).  Until programmers believe that the
compiler will make their code efficient, and that the library routines
are written as efficiently as possible, they will continue to play their
narrow-minded, unmaintainable, non-portable small-scale
efficiency-twiddling games.

Hopelessly disgusted, more than I ever expected to be,

David Chase, Rice University