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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html