GLsizeiptr and GLintptr defined incorrectly?

[bemoody]

According to the GL specs, the types GLsizeiptr and GLintptr should be the size of a pointer (as the 'ptr' suffix would suggest.)

This is supported by the <GL/glext.h> supplied by the MinGW-w64 cross compiler (mingw-w64-common 6.0.0-3 on Debian):

typedef ptrdiff_t GLsizeiptr;
typedef ptrdiff_t GLintptr;
...
typedef ptrdiff_t GLsizeiptrARB;
typedef ptrdiff_t GLintptrARB;

libepoxy 1.5.3 agrees:

typedef ptrdiff_t GLintptr;
typedef ptrdiff_t GLsizeiptr;
...
typedef ptrdiff_t GLintptrARB;
typedef ptrdiff_t GLsizeiptrARB;

However, libepoxy 1.5.5 disagrees:

typedef long khronos_intptr_t;
typedef long khronos_ssize_t;
...
typedef khronos_intptr_t GLintptr;
typedef khronos_intptr_t GLintptrARB;
typedef khronos_ssize_t GLsizeiptr;
typedef khronos_ssize_t GLsizeiptrARB;

Which is correct? What does the implementation of, say, glBindBuffersRange() expect, on 64-bit Windows?

[ebassi]

The header is generated from gl.xml, which says:

<type requires="khrplatform">typedef khronos_intptr_t <name>GLintptr</name>;</type>
<type requires="khrplatform">typedef khronos_ssize_t <name>GLsizeiptr</name>;</type>

but, sadly, not every system provides a khrplatform.h, and we can't detect if an header exists before including it; this means we get to define a bunch of types that should be in that header.

I guess it should be possible to change those definitions depending on the platform.

[ebassi]

Could you try #247 and see if it fixes the problem? I don't have a Windows 64 bit build I can test on, at the moment.

[bemoody]

Thanks for the quick response! At the moment I don't have a Windows system handy either. Actually trying to come up with a simple and definitive test case is a little tricky as well... for one thing, it seems that Mesa/Gallium has problems if you try to create a single buffer larger than 4 GiB. One simple test that does work with Mesa is to try running: GLint buffer; glGenBuffers(1, &buffer); glBindBuffer(GL_ARRAY_BUFFER, buffer); glBufferData(GL_ARRAY_BUFFER, -1, NULL, GL_STATIC_DRAW); which, according to the man page, ought to produce a GL_INVALID_VALUE error. - on X11 Mesa (32-bit or 64-bit), it generates an error; - on 64-bit Wine, when applying the patch from #247, it generates an error; - on 64-bit Wine, without that patch, it doesn't generate an error (and instead allocates a buffer of size 2^32-1.) But of course that's Wine and corner cases like these might not be completely accurate with respect to the behavior on Windows.