Re: sizeof(struct ...)

From: Junio C Hamano <junkio@cox.net>
Date: Nov 23, 2006, 20:47 UTC
Message-ID: <7vpsbdkhzc.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <45659781.5050005@lsrfire.ath.cx>

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

Show 17 quoted lines

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