Bug 392

Summary: 32bit/64bit values and arrays are misrepresented
Product: [JogAmp] Gluegen Reporter: Sven Gothel <sgothel>
Component: coreAssignee: Sven Gothel <sgothel>
Status: VERIFIED FIXED    
Severity: critical    
Priority: P2    
Version: 2   
Hardware: pc_x86_32   
OS: all   
Type: DEFECT SCM Refs:
7220416bcef3140883d3966d921442feae3107c4 84e5ba7a4821469f43c0f4bbeaa8e383b203d050
Workaround: ---

Description Sven Gothel 2010-03-29 19:53:43 CEST
Bugs:

- PointerBuffer is used to map 64bit integer values,
  which is illegal due to the latest PointerBuffer changes,
  where the underlying ByteBuffer is either 32bit wide 
  or 64bit wide (in respect to the pointer size).

  The PointerBuffer semantic itself is correct, 
  but no more suitable to represent 64bit values and arrays.

  A Int64Buffer (LongBuffer does not exist in CDC/CVM patch)
  should be used instead.

- Determine use of Int64Buffer and PointerBuffer

  Assuming the 1st step being solved, it has to determined 
  for which cases gluegen shall map a type to a PointerBuffer.

  All pointer pointer types, regardless of a Opaque mapping, ie:

  +++
  typedef struct __MYAPIConfig * MYAPIConfig;

  Opaque long MYAPIConfig

  void foo(MYAPIConfig * ptrarray);
  +++

  The argument 'ptrarray' must be represented as a PointerBuffer
  otherwise data is misrepresented in case:
    - 32bit machines _and_
    - array semantics - more than one value is being used
Comment 1 Sven Gothel 2010-03-29 19:54:49 CEST
Solved as described ..
Comment 2 Sven Gothel 2010-03-29 22:56:28 CEST
    - PointerBuffer: Adding methods
        PointeRBuffer referenceBuffer(int index, Buffer data)
        PointeRBuffer referenceBuffer(Buffer data)
    
        Buffer getReferencedBuffer(int index)
        Buffer getReferencedBuffer()
    
      Adding a reference of a given direct Buffer
      to this pointer buffer, and retrieving a
      previously referenced direct Buffer.
    
      This allows a more convenient handling of PointerBuffer
      with the user API's ..