Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pacbell!att-ih!att-cb!clyde!watmath!rbutterworth From: rbutterworth@watmath.waterloo.edu (Ray Butterworth) Newsgroups: comp.lang.c Subject: Re: strcpy Message-ID: <17982@watmath.waterloo.edu> Date: 2 Apr 88 21:17:19 GMT References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <10895@mimsy.UUCP> Organization: U of Waterloo, Ontario Lines: 27 In article <10895@mimsy.UUCP>, chris@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 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.