Bug 374 - GL.GL_CLIENT_ALL_ATTRIB_BITS should be type int
Summary: GL.GL_CLIENT_ALL_ATTRIB_BITS should be type int
Status: VERIFIED INVALID
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All all
: P3 normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2009-05-13 08:19 CEST by Sven Gothel
Modified: 2010-11-10 20:22 CET (History)
0 users

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:51:48 CET


---- Reported by kitfox 2009-05-13 20:19:08 ----

GL.GL_CLIENT_ALL_ATTRIB_BITS is currently type long.  It should be type int.



---- Additional Comments From kbr 2009-05-13 22:38:19 ----

The use of long for this value is deliberate because of the lack of unsigned integer values in the Java 
language. GlueGen automatically picks the next larger type when the sign bit is set, as in this value. I 
don't remember exactly when we made the change to GlueGen but I am pretty sure it was motivated by 
incorrect glue code generation for some set of C APIs, possibly OpenGL APIs. There is no plan to change 
this unless there is a strong reason to do so.





---- Additional Comments From kitfox 2009-05-14 04:35:16 ----

Well, right now you can't pass it to GL.glPushClientAttrib(), which only accepts
integers.  I presume that casting it to int would chop off some important bits.



--- Bug imported by sgothel@jausoft.com 2010-03-24 07:51 EDT  ---

This bug was previously known as _bug_ 374 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=374
Comment 1 Sven Gothel 2010-11-10 20:22:15 CET
Java's conversion works as demonstrated below:

public class PrimitiveIntConversion {
    public static void main(String [] args) {
        int i1 = 0xffffffff;   // equals -1
        int i2 = -1;           // equals 0xffffffff
        long l1 = 0xffffffffL; // equals 4294967295
        long l2 = 0xffffffff;  // implicit conversion: 0xffffff == -1 -> 0xffffffffffffffffL == -1

        System.out.println("i1 : 0x"+Integer.toHexString(i1) + ", "+i1);
        System.out.println("i2 : 0x"+Integer.toHexString(i2) + ", "+i2);
        System.out.println("l1 : 0x"+Long.toHexString(l1) + ", "+l1);
        System.out.println("l2 : 0x"+Long.toHexString(l2) + ", "+l2);

        l1 = i1;
        System.out.println("conv1: i1 -> l1 : 0x"+Long.toHexString(l1) + ", "+l1);

        i1 = (int)l1;
        System.out.println("conv1: l1 -> i1 : 0x"+Integer.toHexString(i1) + ", "+i1);
    }
}

i1 : 0xffffffff, -1
i2 : 0xffffffff, -1
l1 : 0xffffffff, 4294967295
l2 : 0xffffffffffffffff, -1
conv1: i1 -> l1 : 0xffffffffffffffff, -1
conv1: l1 -> i1 : 0xffffffff, -1

+++++++++++

Hence it is reversible and the bit pattern remains,
see the conversion of initial l2 and l1 -> i1.

For me this would imply that we could change Gluegen's 'long' typing, to use int.
However, it is a good hint of GlueGen, that something is 'odd'.

so it is definitely not a bug.