strcpy

Ray Butterworth rbutterworth at watmath.waterloo.edu
Sun Apr 3 07:17:19 AEST 1988


In article <10895 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> I would not mind having to change this if the standard mandated
> left-to-right copying (which has a duplication effect on (p+n,p)-style
> overlapping strings).  Alternatively, the standard could proclaim
> that if the strings overlap and dst<src, the copy is done left-to-
> right, otherwise the result is implementation dependent; this, however,
> is an overly grotesque description.  I prefer the simple and well-
> defined semantics of `if the strings overlap, the copy acts as if
> it were performed from left to right, one byte at a time.'

I'm not disagreeing what you said, only with the way you said it.
The terms "left-to-right" and "right-to-left" can be misleading.
Standard C can presumably be used in countries where the natural
direction of the language is right-to-left (e.g. Hebrew or Arabic)
rather than left-to-right (e.g. English or French).  In such an
anvironment, one would consider the terminating nul on a string
to be its left-most character, not its right-most as we would in
English.  Similarly, many of us that use VAX or other similar
equipment tend to think of the bytes being laid out in memory
numbered right-to-left (then shorts, ints, and longs line up
nicely without any of the complications that arise if one thinks
in terms of byte-swapping).

If the standard is going to specify an order for strcpy,
(and I really see no reason why it shouldn't), please let
that order be in terms of "start-to-end" or "low-to-high address"
or some other notation that doesn't presume which end of a string
is the "right" end.



More information about the Comp.lang.c mailing list