[Xcb] [Bug 23403] compiler padding causes reply parsing to use incorrect offsets

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Jul 26 11:30:40 PDT 2012


https://bugs.freedesktop.org/show_bug.cgi?id=23403

--- Comment #3 from David Faure <faure at kde.org> 2012-07-26 11:30:40 PDT ---
I just hit this issue while porting the KDE Framework kidletime to XCB (since
Qt5 uses XCB).

xcb/sync.h says (with my comments added about field size) :

typedef struct xcb_sync_systemcounter_t {
    xcb_sync_counter_t counter; /**<  */                  // 4 bytes
    xcb_sync_int64_t   resolution; /**<  */               // 8 bytes
    uint16_t           name_len; /**<  */                 // 2 bytes
} xcb_sync_systemcounter_t; // sizeof says 16 bytes due to padding

but sync.c (in the XCB sources) says:

char *
xcb_sync_systemcounter_name (const xcb_sync_systemcounter_t *R  /**< */)
{
    return (char *) (R + 1);
}

Shouldn't that be

char *
xcb_sync_systemcounter_name (const xcb_sync_systemcounter_t *R  /**< */)
{
    return (char *) (R) + 14;
}
(gdb confirms that the name is after the struct, as I expected).

Apparently this comes from c_client.py, in the code that says
        if field.prev_varsized_field == None:
            _c('    i.data = (%s *) (R + 1);', field.c_field_type)
which comes from field.type.fixed_size(), but I can't find the definition of
fixed_size() anywhere...

I don't really understand how the presence of 2 bytes of padding is causing a
"+14" to turn into a "+1"?

Alan: thanks for the workaround.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the Xcb mailing list