[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