Path: utzoo!attcan!uunet!cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!ucla-cs!twinsun!eggert
From: eggert@twinsun.com
Newsgroups: comp.lang.c
Subject: Is ``char c; strcpy(&c,"");'' ANSI C?
Message-ID: <30@looney.twinsun.com>
Date: 24 Aug 89 18:08:18 GMT
Sender: news@twinsun.com
Reply-To: eggert@twinsun.com (Paul Eggert)
Organization: Twin Sun Inc.
Lines: 41

Suppose we have ``strcpy'' as defined in K&R 5.5, p.106:

	void strcpy(char *s, char *t) { while (*s++ = *t++) ; }
Then
	...  char c; strcpy(&c, ""); ...		(1)

is not ANSI C, because strcpy calculates (&c) + 1, violating K&R A7.6, p.205,
which says pointer arithmetic can be applied only to a ``pointer to an object
in an array''.  Shouldn't (1) be invalid even if we invoke the standard
library's strcpy(), too?  And by extension, shouldn't the following calls to
standard routines be invalid too?

	...  char c; fread(&c, 1, 1, stdin); ...	(2)
	...  char c; read(0, &c, 1); ...		(3)

Two plausible answers to this question are:

	A.  Certain arguments to standard routines must be arrays.
	Therefore, (1), (2) and (3) are invalid calls to standard routines.

	B.  The standard library must never assume that it is being passed a
	pointer to an array if a pointer to an array containing a single
	object would be valid in that position.  An implementer must not follow
	K&R's version of strcpy, but must rewrite its body, e.g. as:

			while (*s = *t)
				s++, t++;
	or even as:
			if (*s = *t) {
				/* Both *s and *t must be arrays. */
				s++, t++;
				while (*s++ = *t++)
					;
			}

	or use some other, perhaps machine-dependent, code.

(A) seems forced, since (3) at least is a common idiom.

(B) seems overly hopeful: can we really expect implementers to get this right,
	when K&R point in the wrong direction?