Re: sizeof(struct ...)

[Junio C Hamano <junkio@cox.net>]

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Gerrit Pape schrieb:
>...
>> It's because sizeof(struct zip_local_header) is 32, zip_dir_header 48,
>> and zip_dir_trailer 24, breaking the zip files.  Compiling with
>> -fpack-struct seemed to break other things, so I for now I ended up with
>> this (not so nice) workaround.
>
> Hm, yes, this use sizeof() is not strictly correct.  But I'd very much
> like to keep being lazy and let the compiler to do the summing.  How
> about this patch instead?  Does it work for you, Gerrit?
>...
> @@ -35,6 +35,7 @@ struct zip_local_header {
> 	unsigned char size[4];
> 	unsigned char filename_length[2];
> 	unsigned char extra_length[2];
> +	unsigned char _end[0];
> };

While I think relying on the compiler to add no pad in the
middle of the structure that has only unsigned char array
members, making the compiler to sum the member length using
offsetof() is a reasonable approach to avoid hardcoding the size
of on-disk structure representation, zero-length member is not
portable.

We need to deal with tail padding in any case, and this _end[N]
is essentially a manual tail padding when N > 0, so I think that
the code should work even if you change these to _end[1], and
that would be a reasonably clean solution to this problem.