Re: [PATCH 1/9] Define a structure for object IDs.

[Michael Haggerty <mhagger@alum.mit.edu>]

On 05/05/2014 11:50 AM, David Kastrup wrote:
> 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.

> 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/