From: tfb@tfeb.org (Tim Bradshaw)
Subject: [TUHS] C declarations.
Date: Mon, 15 May 2017 07:46:21 +0100 [thread overview]
Message-ID: <E0BCD6A5-33EC-413A-B590-B1F801D072F5@tfeb.org> (raw)
In-Reply-To: <20170513231121.0DB3A1274787@macaroni.inf.ed.ac.uk>
On 14 May 2017, at 00:11, Richard Tobin <richard at inf.ed.ac.uk> wrote:
>
> If a subprogram reference causes a dummy argument in the referenced
> subprogram to become associated with another dummy argument in the
> referenced subprogram, neither dummy argument may become defined
> during execution of that subprogram.
I think the purpose of that is to allow compilers to assume that if you pass two array arguments (say) to a routine then they are really different chunks of memory, so it can optimize things (ie it does not need to worry about the various hazards that happen if they are secretly the same memory).
next prev parent reply other threads:[~2017-05-15 6:46 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-13 23:11 Richard Tobin
2017-05-15 6:46 ` Tim Bradshaw [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-05-15 18:47 Steve Johnson
2017-05-15 19:54 ` Bakul Shah
2017-05-16 7:25 ` George Ross
2017-05-14 14:11 Doug McIlroy
2017-05-14 14:58 ` Steve Nickolas
2017-05-12 14:04 Richard Tobin
2017-05-11 21:49 Ron Natalie
2017-05-11 22:01 ` Arthur Krewat
2017-05-11 23:44 ` Dave Horsfall
2017-05-11 22:03 ` David Arnold
2017-05-11 22:32 ` Larry McVoy
2017-05-11 22:41 ` Ron Natalie
2017-05-13 1:24 ` Larry McVoy
2017-05-13 2:45 ` Ron Natalie
2017-05-13 12:20 ` Michael Kjörling
2017-05-13 12:35 ` Tim Bradshaw
2017-05-13 12:42 ` Michael Kjörling
2017-05-13 15:36 ` Stephen Kitt
2017-05-14 1:59 ` Lawrence Stewart
2017-05-14 2:23 ` Dave Horsfall
2017-05-14 4:24 ` Bakul Shah
2017-05-14 6:12 ` Steve Johnson
2017-05-14 6:48 ` Bakul Shah
2017-05-14 23:06 ` Ron Natalie
2017-05-14 23:34 ` Arthur Krewat
2017-05-15 0:14 ` Dan Cross
2017-05-15 0:23 ` Ron Natalie
2017-05-15 3:43 ` Random832
2017-05-15 0:40 ` Larry McVoy
2017-05-15 2:00 ` Nevin Liber
2017-05-15 10:21 ` Tony Finch
2017-05-15 4:35 ` Dave Horsfall
2017-05-15 4:54 ` Bakul Shah
2017-05-15 5:01 ` Dave Horsfall
2017-05-15 12:58 ` Michael Kjörling
2017-05-15 16:58 ` Dave Horsfall
2017-05-13 13:46 ` Hellwig Geisse
2017-05-13 19:08 ` Random832
2017-05-13 23:21 ` Dave Horsfall
2017-05-14 14:48 ` Nemo
2017-05-13 19:05 ` Random832
2017-05-14 13:14 ` Derek Fawcus
2017-05-12 0:15 ` Bakul Shah
2017-05-12 2:41 ` Theo Pavlidis
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=E0BCD6A5-33EC-413A-B590-B1F801D072F5@tfeb.org \
--to=tfb@tfeb.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).