Bug 374

Summary: GL.GL_CLIENT_ALL_ATTRIB_BITS should be type int
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: coreAssignee: Sven Gothel <sgothel>
Status: VERIFIED INVALID    
Severity: normal    
Priority: P3    
Version: 1   
Hardware: All   
OS: all   
Type: DEFECT SCM Refs:
Workaround: ---

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.