From: David Kastrup <dak@gnu.org>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Johannes Sixt <j6t@kdbg.org>,
Michael Haggerty <mhagger@alum.mit.edu>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
git@vger.kernel.org
Subject: Re: [PATCH 1/9] Define a structure for object IDs.
Date: Mon, 05 May 2014 11:50:11 +0200 [thread overview]
Message-ID: <87d2fstuzw.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87vbtk60lh.fsf@igel.home> (Andreas Schwab's message of "Mon, 05 May 2014 11:23:06 +0200")
Andreas Schwab <schwab@linux-m68k.org> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> It does not as far as I can see guarantee that a pointer to something
>> of the same type of its first member can be converted to a pointer to
>> a struct even if the struct only contains a member of such type.
>
> This sentence doesn't make any sense.
I disagree.
> If you have an object of struct type
Your premise is _not_ assumed in my statement. My premise was "a
pointer to something of the same type of [the struct's] first member".
That does quite explicitly _not_ state that an object of struct type is
in existence.
> then any pointer to the first member of the object can only be a
> pointer to the one and same object.
The case we are talking about is basically passing a pointer to some
actual bonafide toplevel unsigned char [20] object to a routine that
expects a pointer to a struct _only_ containing one such
unsigned char [20] element.
This is the situation we have to deal with if a caller has not been
converted to using such a struct, but the called function does.
More seriously, this is the situation we have to deal with when our SHA1
is actually embedded in some header or whatever else that is actually
available only inside of a larger byte buffer.
In that case, the standard does not permit us converting the address
where that SHA1 is into a pointer to struct. It may well be that this
will fall under the "let's ignore the standard and write for "sensible"
compilers/architectures" dictum, but if it doesn't, it might be
necessary to first copy the data to a struct before passing it to
routines expecting a pointer to struct.
--
David Kastrup
next prev parent reply other threads:[~2014-05-06 16:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-03 20:12 [RFC PATCH 0/9] Use a structure for object IDs brian m. carlson
2014-05-03 20:12 ` [PATCH 1/9] Define " brian m. carlson
2014-05-04 6:07 ` Michael Haggerty
2014-05-04 9:21 ` Johannes Sixt
2014-05-04 9:43 ` David Kastrup
2014-05-04 10:55 ` Andreas Schwab
2014-05-04 20:18 ` Johannes Sixt
2014-05-04 21:31 ` Andreas Schwab
2014-05-05 5:19 ` David Kastrup
2014-05-05 9:23 ` Andreas Schwab
2014-05-05 9:33 ` James Denholm
2014-05-05 9:50 ` David Kastrup [this message]
2014-05-05 10:52 ` Michael Haggerty
2014-05-05 11:05 ` Andreas Schwab
2014-05-05 11:23 ` David Kastrup
2014-05-05 18:16 ` Felipe Contreras
2014-05-04 12:29 ` Duy Nguyen
2014-05-04 16:07 ` brian m. carlson
2014-05-04 16:48 ` Andreas Schwab
2014-05-04 17:07 ` David Kastrup
2014-05-04 17:24 ` Andreas Schwab
2014-05-04 17:44 ` David Kastrup
2014-05-04 18:01 ` Andreas Schwab
2014-05-03 20:12 ` [PATCH 2/9] bisect.c: convert to use struct object_id brian m. carlson
2014-05-03 20:12 ` [PATCH 3/9] archive.c: " brian m. carlson
2014-05-03 20:12 ` [PATCH 4/9] zip: use GIT_OID_HEXSZ for trailers brian m. carlson
2014-05-03 20:12 ` [PATCH 5/9] branch.c: convert to use struct object_id brian m. carlson
2014-05-03 20:12 ` [PATCH 6/9] bulk-checkin.c: " brian m. carlson
2014-05-03 20:12 ` [PATCH 7/9] bundle.c: convert leaf functions to " brian m. carlson
2014-05-06 14:42 ` Michael Haggerty
2014-05-03 20:12 ` [PATCH 8/9] cache-tree: convert struct cache_tree to use object_id brian m. carlson
2014-05-06 14:53 ` Michael Haggerty
2014-05-06 15:02 ` Michael Haggerty
2014-05-03 20:12 ` [PATCH 9/9] diff: convert struct combine_diff_path to object_id brian m. carlson
2014-05-06 15:08 ` Michael Haggerty
2014-05-03 22:49 ` [RFC PATCH 0/9] Use a structure for object IDs brian m. carlson
2014-05-04 6:35 ` Michael Haggerty
2014-05-04 9:19 ` Johannes Sixt
2014-05-04 17:54 ` brian m. carlson
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=87d2fstuzw.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=mhagger@alum.mit.edu \
--cc=sandals@crustytoothpaste.net \
--cc=schwab@linux-m68k.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).