Unpack or Compiler issue?

[newdep]

Hello Lutz,



Im running into something strange which i cant explain.



Im using an .so file with unpack to read from.

 

The C code contains some structures but somehow i always need

to access those structures with an "lu" in unpack. Where the structure

itself contains all different kinds of lenghts.. its very odd..



Could that be a Compiler issue ?



Regards, Norman.

[Lutz]

Can you give me an example? How does the structure look like and how is it returned from C? Or are you talking of structures inside structures? I need to see the 'C' code to help you.



Also did you read http://www.newlisp.org/index.cgi?page=Compiling_and_Importing_Libraries">http://www.newlisp.org/index.cgi?page=C ... _Libraries">http://www.newlisp.org/index.cgi?page=Compiling_and_Importing_Libraries in the Tips&Tricks section? There is a structure example in the last subchapter.



Lutz

[newdep]

Hi Lutz,



I only have this with a specific example, normaly it works fine and

also nested struct work for me finaly...



Try to unpack the following:



In the SDL-1.2.7 source code is the header file names SDL_video.h

where the structure is called: SDL_Surface. You will notice that this

structure contains different sized of variables But unpacking will only

work using all "ul" thus 4 bytes.. very very odd..



If you have time you could try it...



here a small exmaple on how that works ->

(Where screen contains the SDL_Surface data)



;; linux example...

(constant 'lib "libSDL-1.2.so.0")

(constant 'SDL_INIT_VIDEO 0x00000020)

(constant 'SDL_HWSURFACE  0x00000001)



(import lib "SDL_Init")

(import lib "SDL_Quit")

(import lib "SDL_SetVideoMode")



(SDL_Init SDL_INIT_VIDEO)



(setq screen (SDL_SetVideoMode 800 600 8 SDL_HWSURFACE))

(setq struct (unpack "lu lu lu lu lu lu lu lu lu lu lu lu lu lu" screen))



(SDL_Quit)











Regards, Norman.

[Lutz]

in SDL_surface except fot the fifth structure elelement: Uint16 pitch, everything is 32bits so the "lu" format is the right thing for all the others.



In the case of Uint16, it pack it into 32bit, becuase if not, then all subsequent structure members would be located on uneven 32 bit borders. The following experiment confirms this:

Code Select Expand


#include <stdio.h>

struct mystruct {
        short int x;
        int z;
        short int y;
        } data;

struct mystruct * foo(void)
{
data.x = 123;
data.y = 456;
data.z = sizeof(data);

return(&data);
}

> (import "/usr/home/nuevatec" "foo")
/usr/home/nuevatec: invalid file format
problem loading library in function import : "/usr/home/nuevatec"

> (import "/usr/home/nuevatec/test.so" "foo")
foo <281A1588>
> (unpack "lu lu lu" (foo))
(123 12 456)

>


In this case the 16bit variables x and y are not on a 32bit border and the compiler packs them at 32 bit. The sixeof(data) in data.z returns 12 which is 3 times 4.



On the other side if you do:

Code Select Expand


#include <stdio.h>^M

struct mystruct {
        short int x;
        short int y;
        int z;
        } data;

struct mystruct * foo(void)
{
data.x = 123;
data.y = 456;
data.z = sizeof(data);

return(&data);
}

> (import "/usr/home/nuevatec/test.so" "foo")
foo <281A1588>
> (unpack "u u lu" (foo))
(123 456 8)
>


In this second example the 16bit x and y are packed evenly, so the z does not have to go over a 32 bit border and the whole structure is smaller with 8 bytes.



Lutz

[newdep]

Thanks Lutz for explaining this,

My background on C goes only upto 16 Bits ;-)

Thats why im getting confused about this 32Bits structures..



But its clear now..:-)



Regards, Norman.