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  object to a routine that
> expects a pointer to a struct _only_ containing one such
> unsigned char  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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html