Path: utzoo!attcan!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: X3J11 Pleasanton meeting summary
Message-ID: <14129@smoke.BRL.MIL>
Date: 12 Oct 90 13:59:29 GMT
References: <1737:Oct803:02:5890@kramden.acf.nyu.edu> <14049@smoke.BRL.MIL> <1990Oct11.203338.16419@sq.sq.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 39

In article <1990Oct11.203338.16419@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
>But what if func was written as follows?
>	void func (void *p) {int *ip = p; ip[7] = 0; }
>Does ip also point to the element a[1][0] in the array a[1],

Yes.  The implied simple assignments to and from void* do not adversely
affect the value of the int*.  The conversion from int[] to int* that
occurred on the function call resulted in a pointer to a[1][0], so the
value in "ip" must point there also.

>and is this therefore still non-conforming?

The interesting aspect of the question is whether the underlying shape
of a[1] is still in force.  In practically all C implementations, of
course, such detailed type information would have been "scraped off"
by assignment through the void* knothole.  Taking the standard as a
whole into account, specifically malloc()'s role, I would say that the
clear intent of X3J11 was that the additional shape information is
expected to have been scraped off.

The other important aspect is whether or not 3.3.6 requires that ip[7]
then work.  By the previous argumentation, I would say that it is not
required to work, i.e. that the code is still not strictly conforming.
I would be quite surprised, however, to learn of a real implementation
that would take the necessary pains to make this usage fail.

>If so... can memcpy() really be implemented in ANSI C, and used to
>copy arbitrary objects?

Certainly memcpy() can be used to copy arbitrary objects in any
conforming implementation.  What you're really asking is whether a
strictly conforming implementation of memcpy() is possible.  I think
the conclusion is that it is not, but that a conforming (but not
strictly conforming) implementation would be portable in practice.
Remember that there is no requirement on the internal structure of an
implementation, so long as it provides the specified functionality and
obeys the other constraints (such as not infringing on the application
name space).  Undoubtedly, many memcpy() implementations will be done
via assembly language, not coded in any flavor of C.