Bozos
David Chase
rbbb at rice.ARPA
Thu Mar 14 08:05:04 AEST 1985
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
More information about the Comp.lang.c
mailing list