Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: strcpy specifications
Message-ID: <10987@mimsy.UUCP>
Date: 9 Apr 88 03:50:00 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <4343@ihlpf.ATT.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 69

In article <4343@ihlpf.ATT.COM> nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
>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 suppose to be *implemented*).

Nope.  I can define what strcpy should do without saying how it should
do it:


    char *strcpy(char *dst, char *src);

0.  copies string `src' to `dst'.  `src' and `dst' shall not overlap.

or

1.  copies string `src' to `dst'; if src and dst overlap, the result
    is implementation-defined.

or

2.  copies string `src' to `dst' nondestructively.

or

3.  copies string `src' to `dst' such that the copy is nondestructive
    when src and dst are distinct or when src < dst.

or

4.  copies string `src' to `dst'.  By the time strcpy returns, the
    result is as if the copy were done using the following code:

	while ((*dst++ = *src++) != 0) /*void*/;

>There is no 'such that' part in the specification of strcpy().

In *whose* specification?

>Strcpy(), according to the man page, INCLUDING THE WARNING

What warning?  There is no warning in my string(3).  Maybe the warning
in yours is a bug :-) .

>You are saying that overlapping does *not* yield surprises, which is a direct
>contradiction with the specification.

WHAT specification?

The dpANS uses something like number 1 above; I have been saying that
it may be best for it to use any of 2, 3, or 4.  V7 Unix uses none of
the above.

As general design principles, let me offer these statements:
  - provide as few primitives as you can get away with;
  - make them as general as possible.

Moving a string within a single buffer is a reasonable thing to want to
do; if it is cheap enough to do that with the same primitive that moves
strings from one buffer to another, I would say it should be done.  I
think having separate `memcpy' and `memmove' routines is a mistake,
just as I think having multiple kinds of files (blocked, unblocked,
random, sequential, ...) in an O/S is a mistake.  If you must add a
feature, or a restriction, or a new routine, make sure it carries its
weight (as dmr put it).  I think allowing overlapping strings in
strcpy carries its weight better than does asking people to use
memmove(dst, src, strlen(src)).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris