Bug 838928 - bad cast, not 64-bit clean, dict_allocate_and_serialize()
bad cast, not 64-bit clean, dict_allocate_and_serialize()
Product: GlusterFS
Classification: Community
Component: core (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Amar Tumballi
Depends On:
  Show dependency treegraph
Reported: 2012-07-10 09:05 EDT by Kaleb KEITHLEY
Modified: 2013-12-18 19:08 EST (History)
2 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-24 13:19:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kaleb KEITHLEY 2012-07-10 09:05:38 EDT
Description of problem:

All calls to dict_allocate_and_serialize() pass the address of a 32-bit type, but cast it to a 64-bit pointer type (size_t *). This happens to work on LE machines, but even if it's benign, it's still a bug. On BE machines it is not benign.

Version-Release number of selected component (if applicable): All.

How reproducible: build/run on a BE machine, e.g. SPARC or PPC

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Found by xinfeng.liu@gmail.com, email on gluster-devel@nongnu.org mailing list
Comment 1 Kaleb KEITHLEY 2012-07-10 09:32:22 EDT
In every call to dict_allocate_and_serialize(), the underlying 'len' param is always a u_int, so:
 a) why is the param a size_t* ?
 b) and then why have extra code in GF_PROTOCOL_DICT_SERIALIZE to work around it?

By changing the param in dict_allocate_and_serialize() to a u_int* we only need to fix a few files and then we have 64-bit clean code everywhere we call dict_allocate_and_serialize().
Comment 2 Vijay Bellur 2012-07-12 03:31:56 EDT
CHANGE: http://review.gluster.com/3642 (calls to dict_allocate_and_serialize() are not 64-bit clean) merged in master by Anand Avati (avati@redhat.com)

Note You need to log in before you can comment on or make changes to this bug.