From: Anthony Liguori <aliguori@us.ibm.com>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: Michael A Fetterman <Michael.Fetterman@cl.cam.ac.uk>,
Mark Williamson <maw48@cl.cam.ac.uk>,
xen-devel@lists.xensource.com, Gerd Knorr <kraxel@bytesex.org>
Subject: Re: [patch] pagetable cleanups
Date: Thu, 14 Apr 2005 14:07:40 -0500 [thread overview]
Message-ID: <1113505660.29794.13.camel@localhost> (raw)
In-Reply-To: <1113503253.16993.13.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2005-04-14 19:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-12 18:58 [patch] pagetable cleanups Gerd Knorr
2005-04-14 12:25 ` Michael A Fetterman
2005-04-14 15:01 ` Gerd Knorr
2005-04-14 14:48 ` Mark Williamson
2005-04-14 18:27 ` Hollis Blanchard
2005-04-14 19:07 ` Anthony Liguori [this message]
2005-04-14 19:20 ` Hollis Blanchard
2005-04-14 19:30 ` Gerd Knorr
2005-04-14 16:47 ` Christian Limpach
-- strict thread matches above, loose matches on Subject: below --
2005-04-14 14:14 Ian Pratt
2005-04-14 15:11 Ian Pratt
2005-04-14 15:31 ` Gerd Knorr
2005-04-14 19:33 Ian Pratt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1113505660.29794.13.camel@localhost \
--to=aliguori@us.ibm.com \
--cc=Michael.Fetterman@cl.cam.ac.uk \
--cc=hollisb@us.ibm.com \
--cc=kraxel@bytesex.org \
--cc=maw48@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.