strcpy, enough already!
Dave Sill
dsill at NSWC-OAS.arpa
Fri Apr 15 00:08:20 AEST 1988
[I hate to add fuel to the fire...]
Nevin Liber writes:
>It still IS dependent on the [implementation]; you just want ANSI to put the
>implementation in the specification.
>
>You are not defining *what* the function does (ie, you are not making an
>abstract *description* of the function); you are defining *how* the
>function does a strcpy (ie, how it is [supposed] to be *implemented*).
This is simply not true. Defining strcpy so that it would work right
for overlapping strings WOULD NOT DEFINE HOW STRCPY IS IMPLEMENTED.
There would still be an unlimited number of ways to code strcpy.
I support such a definition because it would break NO existing code
and it would codify existing practice. So who loses? People on
machines whose most efficient block copy is address-descending, maybe.
Perhaps 5% (I'm being generous) of the C-using population. And who
wins? Everybody else who uses or maintains code that made this
non-portable assumption.
=========
The opinions expressed above are mine.
"It's said that premature optimization is the root of all evil."
-- Bill Joy
More information about the Comp.lang.c
mailing list