From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [patch] pagetable cleanups Date: Thu, 14 Apr 2005 14:07:40 -0500 Message-ID: <1113505660.29794.13.camel@localhost> References: <20050412185856.GA5832@bytesex> <20050414150150.GA28071@bytesex> <200504141548.12400.maw48@cl.cam.ac.uk> <1113503253.16993.13.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1113503253.16993.13.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Hollis Blanchard Cc: Michael A Fetterman , Mark Williamson , xen-devel@lists.xensource.com, Gerd Knorr List-Id: xen-devel@lists.xenproject.org On Thu, 2005-04-14 at 13:27, Hollis Blanchard wrote: > So no memcpys at all; the caller fills in the values directly into the > callee's struct. Unless you're dealing with struct assignments. You basically get a memcpy() when you assign structs. The standard makes it pretty clear that the returning a struct is not an lvalue (it's a copy). Unoptimized C will have an inlined memcpy() because of the assignment. Otherwise, the following: foo(b, c).a = 3; Would be valid and this is expressly forbidden by the standard (see section 6.5.2.3). A smart compiler will propagate the copy but it has it's limitations. Once you have sufficiently complex pointer operations in a function there's no guarantee copies will be propagated correctly. Because you cannot rely on the optimization, structs are not typically returned by value. Since this is so rarely done, I'd argue it's more readable to pass a struct as an argument (the fact that some people don't even realize it's possible should support that). Regards, -- Anthony Liguori Linux Technology Center (LTC) - IBM Austin E-mail: aliguori@us.ibm.com Phone: (512) 838-1208