Re: [PATCH 1/9] Define a structure for object IDs.
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- May 5, 2014, 10:52 UTC
- Message-ID
- <53676D6C.4010009@alum.mit.edu>
- In-Reply-To
- <87d2fstuzw.fsf@fencepost.gnu.org>
On 05/05/2014 11:50 AM, David Kastrup wrote:
Show 7 quoted lines
> 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.
If the rewrite is done by first changing data structures and then changing functions in caller -> callee order then (1) the deltas can be pretty small, and (2) such illegal casting should be unnecessary.
Show 10 quoted lines
> 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.
This sounds dangerous even for a "sensible" compiler. For example, I can imagine that a sensible compiler might make the assumption that a sha1 field that it knows was obtained from oid->sha1 is word-aligned, and generate optimized code based on that assumption, even though it otherwise wouldn't have had trouble working with unaligned (unsigned char *) pointers.
Michael
-- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/