Pete Zaitcev wrote:
On Fri, 7 Aug 2009 19:36:28 -0400 (EDT), Rick Peralta <[email protected]> wrote:

I was looking from net_write() & net_read() to see where they were
called and what was passed to them.  struct chunksrv_req & struct
chunksrv_resp_get seem to be the primary structures.

I didn't know how serious you were about it, so I went ahead and
looked at the endian stuff. The immediate issue - the hang of
basic-object - was addressed with the following fix:

diff --git a/server/object.c b/server/object.c
index 4eb62f7..6ea1500 100644
--- a/server/object.c
+++ b/server/object.c
@@ -290,7 +290,7 @@ bool object_get(struct client *cli, bool want_body)
cli->in_len = obj->size; - resp->req.data_len = GUINT32_TO_LE(obj->size);
+       resp->req.data_len = GUINT64_TO_LE((uint64_t)obj->size);
        memcpy(resp->req.checksum, obj->hashstr, sizeof(obj->hashstr));
        resp->req.checksum[sizeof(obj->hashstr)] = 0;
        resp->mtime = GUINT64_TO_LE(obj->mtime);
diff --git a/server/server.c b/server/server.c
index 2ad3db2..161dc67 100644
--- a/server/server.c
+++ b/server/server.c
@@ -639,7 +639,7 @@ static bool cli_resp_xml(struct client *cli, GList *content)
 {
        int rc;
        bool rcb;
-       int content_len = strlist_len(content);
+       size_t content_len = strlist_len(content);
        struct chunksrv_req *resp = NULL;
resp = malloc(sizeof(*resp));
@@ -650,7 +650,7 @@ static bool cli_resp_xml(struct client *cli, GList *content)
memcpy(resp, &cli->creq, sizeof(cli->creq)); - resp->data_len = GUINT64_TO_LE(content_len);
+       resp->data_len = GUINT64_TO_LE((uint64_t)content_len);
cli->state = evt_recycle;

I think type-safety should win the day. So, I am going to work on a set of 'static inline' functions that wrap GUINT* macros. We shouldn't need to add casts to achieve type promotion, in that case.

I think I will name them le32_to_cpu, cpu_to_le16, le64_to_cpu, etc. :)

        Jeff



--
To unsubscribe from this list: send the line "unsubscribe hail-devel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to