From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, Gerrit Pape <pape@smarden.org>
Subject: [PATCH] archive-zip: don't use sizeof(struct ...)
Date: Thu, 23 Nov 2006 23:02:37 +0100 [thread overview]
Message-ID: <45661A7D.9070207@lsrfire.ath.cx> (raw)
In-Reply-To: <7vpsbdkhzc.fsf@assigned-by-dhcp.cox.net>
We can't rely on sizeof(struct zip_*) returning the sum of
all struct members. At least on ARM padding is added at the
end, as Gerrit Pape reported. This fixes the problem but
still lets the compiler do the summing by introducing
explicit padding at the end of the structs and then taking
its offset as the combined size of the preceding members.
As Junio correctly notes, the _end[] marker array's size
must be greater than zero for compatibility with compilers
other than gcc. The space wasted by the markers can safely
be neglected because we only have one instance of each
struct, i.e. in sum 3 wasted bytes on i386, and 0 on ARM. :)
We still rely on the compiler to not add padding between the
struct members, but that's reasonable given that all of them
are unsigned char arrays.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
archive-zip.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index ae5572a..36e922a 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -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[1];
};
struct zip_dir_header {
@@ -55,6 +56,7 @@ struct zip_dir_header {
unsigned char attr1[2];
unsigned char attr2[4];
unsigned char offset[4];
+ unsigned char _end[1];
};
struct zip_dir_trailer {
@@ -66,8 +68,18 @@ struct zip_dir_trailer {
unsigned char size[4];
unsigned char offset[4];
unsigned char comment_length[2];
+ unsigned char _end[1];
};
+/*
+ * On ARM, padding is added at the end of the struct, so a simple
+ * sizeof(struct ...) reports two bytes more than the payload size
+ * we're interested in.
+ */
+#define ZIP_LOCAL_HEADER_SIZE offsetof(struct zip_local_header, _end)
+#define ZIP_DIR_HEADER_SIZE offsetof(struct zip_dir_header, _end)
+#define ZIP_DIR_TRAILER_SIZE offsetof(struct zip_dir_trailer, _end)
+
static void copy_le16(unsigned char *dest, unsigned int n)
{
dest[0] = 0xff & n;
@@ -211,7 +223,7 @@ static int write_zip_entry(const unsigne
}
/* make sure we have enough free space in the dictionary */
- direntsize = sizeof(struct zip_dir_header) + pathlen;
+ direntsize = ZIP_DIR_HEADER_SIZE + pathlen;
while (zip_dir_size < zip_dir_offset + direntsize) {
zip_dir_size += ZIP_DIRECTORY_MIN_SIZE;
zip_dir = xrealloc(zip_dir, zip_dir_size);
@@ -234,8 +246,8 @@ static int write_zip_entry(const unsigne
copy_le16(dirent.attr1, 0);
copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
- memcpy(zip_dir + zip_dir_offset, &dirent, sizeof(struct zip_dir_header));
- zip_dir_offset += sizeof(struct zip_dir_header);
+ memcpy(zip_dir + zip_dir_offset, &dirent, ZIP_DIR_HEADER_SIZE);
+ zip_dir_offset += ZIP_DIR_HEADER_SIZE;
memcpy(zip_dir + zip_dir_offset, path, pathlen);
zip_dir_offset += pathlen;
zip_dir_entries++;
@@ -251,8 +263,8 @@ static int write_zip_entry(const unsigne
copy_le32(header.size, uncompressed_size);
copy_le16(header.filename_length, pathlen);
copy_le16(header.extra_length, 0);
- write_or_die(1, &header, sizeof(struct zip_local_header));
- zip_offset += sizeof(struct zip_local_header);
+ write_or_die(1, &header, ZIP_LOCAL_HEADER_SIZE);
+ zip_offset += ZIP_LOCAL_HEADER_SIZE;
write_or_die(1, path, pathlen);
zip_offset += pathlen;
if (compressed_size > 0) {
@@ -282,7 +294,7 @@ static void write_zip_trailer(const unsi
copy_le16(trailer.comment_length, sha1 ? 40 : 0);
write_or_die(1, zip_dir, zip_dir_offset);
- write_or_die(1, &trailer, sizeof(struct zip_dir_trailer));
+ write_or_die(1, &trailer, ZIP_DIR_TRAILER_SIZE);
if (sha1)
write_or_die(1, sha1_to_hex(sha1), 40);
}
next prev parent reply other threads:[~2006-11-23 22:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-23 10:16 sizeof(struct ...) Gerrit Pape
2006-11-23 12:43 ` René Scharfe
2006-11-23 13:38 ` René Scharfe
2006-11-23 13:55 ` Andy Whitcroft
2006-11-23 15:45 ` René Scharfe
2006-11-23 15:54 ` Erik Mouw
2006-11-23 16:14 ` René Scharfe
2006-11-23 16:19 ` Andy Whitcroft
2006-11-23 17:57 ` René Scharfe
2006-11-23 16:42 ` Erik Mouw
2006-11-23 20:47 ` Junio C Hamano
2006-11-23 22:02 ` René Scharfe [this message]
2006-11-24 8:53 ` [PATCH] archive-zip: don't use " Gerrit Pape
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45661A7D.9070207@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=pape@smarden.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).