Khronos Public Bugzilla
Bug 525 - khrplatform.h incorrectly assumes sizeof(long int) == sizeof(intptr_t)
khrplatform.h incorrectly assumes sizeof(long int) == sizeof(intptr_t)
Status: RESOLVED FIXED
Product: EGL
Classification: Unclassified
Component: Registry
1.4
All Windows
: P3 normal
: ---
Assigned To: Jon Leech
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-04 19:50 PDT by Christohper James Halse Rogers
Modified: 2013-09-30 17:13 PDT (History)
1 user (show)

See Also:


Attachments
Patch (847 bytes, patch)
2013-01-05 00:54 PST, Jonathan Liu
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christohper James Halse Rogers 2011-09-04 19:50:33 PDT
krhplatform.h currently contains:

/*
 * Types that are (so far) the same on all platforms
 */
typedef signed   char          khronos_int8_t;
typedef unsigned char          khronos_uint8_t;
typedef signed   short int     khronos_int16_t;
typedef unsigned short int     khronos_uint16_t;
typedef signed   long  int     khronos_intptr_t;
typedef unsigned long  int     khronos_uintptr_t;
typedef signed   long  int     khronos_ssize_t;
typedef unsigned long  int     khronos_usize_t;

However, 64bit Windows uses an LLP64 model¹, where longs are 32bits and pointers are 64bits.

Thus the definitions khronos_{u,}intptr_t and khronos_{s,u}size_t need to be specialised.

For the C99 case this could just be to typedef the existing {u,}intptr_t, and for POSIX at least to typedef ssize_t to khronos_ssize_t and size_t to khronos_usize_t.

1: http://technet.microsoft.com/en-us/library/bb496995.aspx
Comment 1 Jonathan Liu 2012-12-16 02:47:24 PST
Any update on this?
Comment 2 Jonathan Liu 2013-01-05 00:54:12 PST
Created attachment 131 [details]
Patch
Comment 3 Jon Leech 2013-09-30 17:13:26 PDT
Sorry for the long delay in responding to this. khrplatform.h on the
public registry has been updated with Jonathan's patch.

We ended up delaying on this for a long time because in examing the
change we ran into a different 64-bit problem where EGLint had not
been defined properly as a 64-bit integral type on platforms with
64-bit pointers. This caused quite a lot of discussion about how to
deal with the reality vs. spec language, which we've now proposed a
spec update to in a forum post at

http://www.khronos.org/message_boards/showthread.php/9138-Requesting-feedback-on-disallowing-handle-attribute-values-in-EGLint-attribute-lists?p=29720#post29720