Interface To C Struct That Includes An Array

Interface To C Struct That Includes An Array

[rogermc]

 I'm having problems interfacing the following record to C.

   type API_String is record
      Length  : Interfaces.C.size_t := 0;
      Data    : API_String_Data_Array := (others => Interfaces.C.char'Val (0));
   end record;
   pragma Convention (C_Pass_By_Copy, API_String);

In general it seems OK, however, the following function in which Assimp_Path'Access is returned 
from a C function produces a strange result 

 Result := API_Get_Material_Texture (Material'Access, Tex_Type, unsigned (Tex_Index), Assimp_Path'Access);

The returned Assimp_Path is Length: 16, Data: \vB000phoenix.pcx0000
in which B is a series of four small zeros inside a rectangle.
I haven't been able to find a syntactical explanation for the four small zeros inside a rectangle.

The expected Assimp_Path is Length: 11, Data: phoenix.pcx
Memory inspection indicates that the Length 16 includes both the expected length and character string.

(gdb) print Assimp_Path
$8 = (length => 16, data => (0 => 11, 0, 0, 0, 112, 104, 111, 101, 110, 105, 120, 46, 112, 99, 120, 0 <repeats 1009 times>)

If I shift the Data characters left by four places and change Length to 12, the resultant Assimp_Path is
Length: 16, Data: \vBphoenix.pcx

The C interface is:

      function API_Get_Material_Texture (aMaterial : access API_Material_Tex;
                                         Tex_Type  : AI_Texture_Type;
                                         Index     : Interfaces.C.unsigned;
                                         Path      : access Assimp_Types.API_String := null;
                                         Mapping   : access AI_Texture_Mapping := null;
                                         UV_Index  : access Interfaces.C.unsigned := null;
                                         Blend     : access Interfaces.C.C_float := null;
                                         Op        : access AI_Texture_Op := null;
                                         Map_Mode  : access AI_Texture_Map_Mode := null)
                                         return Assimp_Types.API_Return;
      pragma Import (C, API_Get_Material_Texture, "aiGetMaterialTexture");

Any positive advice or explanation will be appreciated.
Roger

Re: Interface To C Struct That Includes An Array

[rogermc]

On Monday, 17 September 2018 22:01:43 UTC+10, rog...@iinet.net.au  wrote:
> I'm having problems interfacing the following record to C.
> 
>    type API_String is record
>       Length  : Interfaces.C.size_t := 0;
>       Data    : API_String_Data_Array := (others => Interfaces.C.char'Val (0));
>    end record;
>    pragma Convention (C_Pass_By_Copy, API_String);
> 
> In general it seems OK, however, the following function in which Assimp_Path'Access is returned 
> from a C function produces a strange result 
> 
>  Result := API_Get_Material_Texture (Material'Access, Tex_Type, unsigned (Tex_Index), Assimp_Path'Access);
> 


> The returned Assimp_Path is Length: 16, Data:  B000phoenix.pcx0000
> in which B is a series of four small zeros inside a rectangle.
> I haven't been able to find a syntactical explanation for the four small zeros inside a rectangle.
> 
> The expected Assimp_Path is Length: 11, Data: phoenix.pcx
> Memory inspection indicates that the Length 16 includes both the expected length and character string.
> 
> (gdb) print Assimp_Path
> $8 = (length => 16, data => (0 => 11, 0, 0, 0, 112, 104, 111, 101, 110, 105, 120, 46, 112, 99, 120, 0 <repeats 1009 times>)
> 
CORRECTION:
> If I shift the Data characters left by four places and change Length to 12, the resultant Assimp_Path is
> Length: 12, Data:  Bphoenix.pcx
> 
> The C interface is:
> 
>       function API_Get_Material_Texture (aMaterial : access API_Material_Tex;
>                                          Tex_Type  : AI_Texture_Type;
>                                          Index     : Interfaces.C.unsigned;
>                                          Path      : access Assimp_Types.API_String := null;
>                                          Mapping   : access AI_Texture_Mapping := null;
>                                          UV_Index  : access Interfaces.C.unsigned := null;
>                                          Blend     : access Interfaces.C.C_float := null;
>                                          Op        : access AI_Texture_Op := null;
>                                          Map_Mode  : access AI_Texture_Map_Mode := null)
>                                          return Assimp_Types.API_Return;
>       pragma Import (C, API_Get_Material_Texture, "aiGetMaterialTexture");
> 
> Any positive advice or explanation will be appreciated.
> Roger

Re: Interface To C Struct That Includes An Array

[gautier_niouzes]

> phoenix.pcx

Using PCX image files?

Re: Interface To C Struct That Includes An Array

[Roger]

On Monday, September 17, 2018 at 10:26:49 PM UTC+10, gautier...@hotmail.com wrote:
> > phoenix.pcx
> 
> Using PCX image files?

The file initially read by the program is named phoenix_ugv.md2.
phoenix.pcx is presumably a texture file name extracted from phoenix_ugv.md2 by aiGetMaterialTexture using information provided by aMaterial : access API_Material_Tex.
A texture is next supposed to be loaded from the file phoenix.pcx.

So YES to your question.
My problem is just to be able to correctly interpret the file name returned by aiGetMaterialTexture. 

Re: Interface To C Struct That Includes An Array

[gautier_niouzes]

Funnily, the phoenix.pcx available for instance here

https://github.com/jvm-graphics-labs/ogl-dev/tree/master/oglDevTutorials/src/ogldevtutorials/content

is actually a JPEG - you see the "JFIF" signature in any text editor :-).

Re: Interface To C Struct That Includes An Array

[Roger]

On Monday, September 17, 2018 at 11:55:35 PM UTC+10, gautier...@hotmail.com wrote:
> Funnily, the phoenix.pcx available for instance here
> 
> https://github.com/jvm-graphics-labs/ogl-dev/tree/master/oglDevTutorials/src/ogldevtutorials/content
> 
> is actually a JPEG - you see the "JFIF" signature in any text editor :-).

In fact, oglDevTutorials (22 currently) is the code that I’m trying to port to Ada.
Getting the Assimp interface to work is a great challenge.
My phoenix.pcx is from ogldevtutorials/content

Re: Interface To C Struct That Includes An Array

[Lucretia]

On Monday, 17 September 2018 13:01:43 UTC+1, rog...@iinet.net.au  wrote:
> I'm having problems interfacing the following record to C.
> 
>    type API_String is record
>       Length  : Interfaces.C.size_t := 0;
>       Data    : API_String_Data_Array := (others => Interfaces.C.char'Val (0));
>    end record;
>    pragma Convention (C_Pass_By_Copy, API_String);

Variable length things in Ada are problematic no matter what really.

What does the type definition of API_String_Data_Array look like? Is it also Convention => C?

Re: Interface To C Struct That Includes An Array

[Lucretia]

On Monday, 17 September 2018 13:11:34 UTC+1, rog...@iinet.net.au  wrote:
> > 
> CORRECTION:
> > If I shift the Data characters left by four places and change Length to 12, the resultant Assimp_Path is
> > Length: 12, Data:  Bphoenix.pcx

Are you sure the B is correct and not data representation issue? Does the B get used?

Re: Interface To C Struct That Includes An Array

[Jeffrey R. Carter]

On 09/17/2018 02:01 PM, rogermc@iinet.net.au wrote:
> 
> (gdb) print Assimp_Path
> $8 = (length => 16, data => (0 => 11, 0, 0, 0, 112, 104, 111, 101, 110, 105, 120, 46, 112, 99, 120, 0 <repeats 1009 times>)

I have no idea what I'm talking about, so this may be totally useless, but the 
11 0 0 0 at the beginning looks like it might be some sort of encoding marker. 
The first of the 1009 (or is it 1010?) zeros at the end is in position 16 (index 
15), so I presume it's the C string terminator.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: Interface To C Struct That Includes An Array

[Roger]

On Tuesday, September 18, 2018 at 1:25:24 AM UTC+10, Lucretia wrote:
> On Monday, 17 September 2018 13:11:34 UTC+1, rog...@iinet.net.au  wrote:
> > > 
> > CORRECTION:
> > > If I shift the Data characters left by four places and change Length to 12, the resultant Assimp_Path is
> > > Length: 12, Data:  Bphoenix.pcx
> 
> Are you sure the B is correct and not data representation issue? Does the B get used?

My B represents a symbol that I don't understand.
It represents a rectangle containing four small zeros.
Its not something that I either expect or know how to use.

Re: Interface To C Struct That Includes An Array

[Roger]

On Tuesday, September 18, 2018 at 2:29:20 AM UTC+10, Jeffrey R. Carter wrote:
> On 09/17/2018 02:01 PM, rogermc@iinet.net.au wrote:
> > 
> > (gdb) print Assimp_Path
> > $8 = (length => 16, data => (0 => 11, 0, 0, 0, 112, 104, 111, 101, 110, 105, 120, 46, 112, 99, 120, 0 <repeats 1009 times>)
> 
> I have no idea what I'm talking about, so this may be totally useless, but the 
> 11 0 0 0 at the beginning looks like it might be some sort of encoding marker. 
> The first of the 1009 (or is it 1010?) zeros at the end is in position 16 (index 
> 15), so I presume it's the C string terminator.
> 
> -- 
> Jeff Carter
> "Oh Lord, bless this thy hand grenade, that with it thou
> mayst blow thine enemies to tiny bits, in thy mercy."
> Monty Python and the Holy Grail
> 24

The expected data size is 1024, the first character of which is the 112.
The 11 IS  the size of the character string 112, 104, 111, 101, 110, 105, 120, 46, 112, 99, 120,
the last 0 being the (null) string terminator.
The remaining 1009 (or is it 1010?) zeros are just unused character spaces that were initialized with nulls.
The 16 seems to indicate that the whole of the expected data structure (length and data) have been interpreted (somewhere) as data and the 16 is the length of the "data".
I'm wondering if, somehow the "thing" might be a struct containing the required struct:
struct
    length.     (16)
    struct
       length.  (11)
       data      (character string)

There is another C routine that I call that returns the API_String record (struct) correctly.
This correctly returned API_String struct is actually part of another larger structure.

Re: Interface To C Struct That Includes An Array

[Roger]

On Tuesday, September 18, 2018 at 1:24:09 AM UTC+10, Lucretia wrote:
> On Monday, 17 September 2018 13:01:43 UTC+1, rog...@iinet.net.au  wrote:
> > I'm having problems interfacing the following record to C.
> > 
> >    type API_String is record
> >       Length  : Interfaces.C.size_t := 0;
> >       Data    : API_String_Data_Array := (others => Interfaces.C.char'Val (0));
> >    end record;
> >    pragma Convention (C_Pass_By_Copy, API_String);
> 
> Variable length things in Ada are problematic no matter what really.
> 
> What does the type definition of API_String_Data_Array look like? Is it also Convention => C?

I've replaced API_String_Data_Array with its original declaration which was
subtype API_String_Data_Array is char_array (0 .. Max_Length - 1):= (others => Interfaces.C.char'Val (0));


  --  This declaration has been checked OK for Key data. DON'T CHANGE
   type API_String is record
      Length  : Interfaces.C.size_t := 0;
      Data     : char_array (0 .. Max_Length - 1):= (others => Interfaces.C.char'Val (0));
   end record;
   pragma Convention (C_Pass_By_Copy, API_String);

but the same problem remains

Re: Interface To C Struct That Includes An Array

[Roger]

On Tuesday, September 18, 2018 at 8:35:52 AM UTC+10, Roger wrote:
> On Tuesday, September 18, 2018 at 1:25:24 AM UTC+10, Lucretia wrote:
> > On Monday, 17 September 2018 13:11:34 UTC+1, rog...@iinet.net.au  wrote:
> > > > 
> > > CORRECTION:
> > > > If I shift the Data characters left by four places and change Length to 12, the resultant Assimp_Path is
> > > > Length: 12, Data:  Bphoenix.pcx
> > 
> > Are you sure the B is correct and not data representation issue? Does the B get used?
> 
> My B represents a symbol that I don't understand.
> It represents a rectangle containing four small zeros.
> Its not something that I either expect or know how to use.

I now think that the rectangle containing four small zeros is displayed for the ascii code 11 (hex or dec?)
That is B means an undisplayable ASCII "character".
Dec 11 is VT Vertical Tab
Hex 11 is DC1
So the original (without shifting) that is dis[layed seems to be:
Length: 16, Data:  (VT)000phoenix.pcx0 or Length: 16, Data:  (DC1)000phoenix.pcx0
whereas, what it should be is:
Length: 11, Data:  phoenix.pcx

Re: Interface To C Struct That Includes An Array

[Roger]

On Tuesday, September 18, 2018 at 2:29:20 AM UTC+10, Jeffrey R. Carter wrote:
> On 09/17/2018 02:01 PM, rogermc@iinet.net.au wrote:
> > 
> > (gdb) print Assimp_Path
> > $8 = (length => 16, data => (0 => 11, 0, 0, 0, 112, 104, 111, 101, 110, 105, 120, 46, 112, 99, 120, 0 <repeats 1009 times>)
> 
> I have no idea what I'm talking about, so this may be totally useless, but the 
> 11 0 0 0 at the beginning looks like it might be some sort of encoding marker. 
> The first of the 1009 (or is it 1010?) zeros at the end is in position 16 (index 
> 15), so I presume it's the C string terminator.
> 
> -- 
> Jeff Carter
> "Oh Lord, bless this thy hand grenade, that with it thou
> mayst blow thine enemies to tiny bits, in thy mercy."
> Monty Python and the Holy Grail
> 24

As I've explained to Lucretia, the 11 turns out to be an undisplayable ASCII character (either VT or DC1)
which is displayed as a rectangular box containing four small zeros.
So 11 0 0 0 is being interpreted as four chars rather than the expected size_t integer, I think.

Re: Interface To C Struct That Includes An Array

[rogermc]

> I now think that the rectangle containing four small zeros is displayed for the ascii code 11 (hex or dec?)
CORRECTION
The rectangle contains 000B.  I made the mistake because of the very small characters.
The B is obviously the hex code for decimal 11 so:
Dec 11 is VT Vertical Tab
So the original (without shifting) that is displayed seems to be:
Length: 16, Data:  (VT)000phoenix.pcx0 
whereas, what it should be is:
Length: 11, Data:  phoenix.pcx

Re: Interface To C Struct That Includes An Array

[Roger]

I've decided that the problem is not with this output data itself but most probably the result of incorrectly formatted input data to the routine generating it. (Garbage In -> Garbage Out!)
I'm now investigating the input data.
Thanks for the interaction which has helped me to think through the problem more clearly.

Re: Interface To C Struct That Includes An Array

[rakusu_klein]

Probably you pass a link to the whole record somewhere where expected only a link to the data field. The other explanation of binary garbage in the string is that you get somwhere a raw uncutted data, because the aiGetMaterialString cuts the 32-bit prefix and corrects the length in aiString field by itself.

понедельник, 17 сентября 2018 г., 15:01:43 UTC+3 пользователь rog...@iinet.net.au написал:
>    pragma Convention (C_Pass_By_Copy, API_String);
It doesn't seems to be a good idea for me to copy a kilobyte of data on every call.

> The returned Assimp_Path is Length: 16, Data:  B000phoenix.pcx0000
> in which B is a series of four small zeros inside a rectangle.
> I haven't been able to find a syntactical explanation for the four small zeros inside a rectangle.
As I can remember, this icon stays for nonprintable characters.

>       function API_Get_Material_Texture (aMaterial : access API_Material_Tex;
>                                          Tex_Type  : AI_Texture_Type;
>                                          Index     : Interfaces.C.unsigned;
>                                          Path      : access Assimp_Types.API_String := null;
>                                          Mapping   : access AI_Texture_Mapping := null;
>                                          UV_Index  : access Interfaces.C.unsigned := null;
>                                          Blend     : access Interfaces.C.C_float := null;
>                                          Op        : access AI_Texture_Op := null;
>                                          Map_Mode  : access AI_Texture_Map_Mode := null)
>                                          return Assimp_Types.API_Return;
I also notice, that you forget the last argument "unsigned int * flags".

Re: Interface To C Struct That Includes An Array

[rogermc]

On Tuesday, 18 September 2018 18:19:30 UTC+10, rakusu...@fastmail.jp  wrote:
> Probably you pass a link to the whole record somewhere where expected only a link to the data field. The other explanation of binary garbage in the string is that you get somwhere a raw uncutted data, because the aiGetMaterialString cuts the 32-bit prefix and corrects the length in aiString field by itself.
> 
> понедельник, 17 сентября 2018 г., 15:01:43 UTC+3 пользователь rog...@iinet.net.au написал:
> >    pragma Convention (C_Pass_By_Copy, API_String);
> It doesn't seems to be a good idea for me to copy a kilobyte of data on every call.
I agree but I don't know how to avoid it.
Would pragma Convention (C, API_String) be OK?
Also, I'm not sure that API_String is ever actually copied as all the interfacing is by pointers?
> 
> > The returned Assimp_Path is Length: 16, Data:  B000phoenix.pcx0000
> > in which B is a series of four small zeros inside a rectangle.
> > I haven't been able to find a syntactical explanation for the four small zeros inside a rectangle.
> As I can remember, this icon stays for nonprintable characters.
I've since discovered that its actually 000B inside the rectangle, the B obviously being hex for 11 which is the ASCII code for an unprintable character (VT) so its actually (VT)000phoenix.pcx0. The final three zeros above are an error in my report.
> 
> >       function API_Get_Material_Texture (aMaterial : access API_Material_Tex;
> >                                          Tex_Type  : AI_Texture_Type;
> >                                          Index     : Interfaces.C.unsigned;
> >                                          Path      : access Assimp_Types.API_String := null;
> >                                          Mapping   : access AI_Texture_Mapping := null;
> >                                          UV_Index  : access Interfaces.C.unsigned := null;
> >                                          Blend     : access Interfaces.C.C_float := null;
> >                                          Op        : access AI_Texture_Op := null;
> >                                          Map_Mode  : access AI_Texture_Map_Mode := null)
> >                                          return Assimp_Types.API_Return;
> I also notice, that you forget the last argument "unsigned int * flags".
Yes, I seem to have inadvertently used the declaration of GetTexture instead of aiGetMaterialTexture.
Thanks for that observation. I'll add flags to my declaration of API_Get_Material_Texture.

Re: Interface To C Struct That Includes An Array

[Egil H H]

On Tuesday, September 18, 2018 at 1:54:37 PM UTC+2, rog...@iinet.net.au wrote:
> The final three zeros above are an error in my report.

I don't think so. (11, 0, 0, 0) is most likely a 32-bit integer in little-endian format (interpreted as a byte array, with each byte printed in decimal), and all of it represents the string length (and since the length is specified, you should not assume a zero-terminated string)


-- 
~egilhh

Re: Interface To C Struct That Includes An Array

[rogermc]

On Tuesday, 18 September 2018 22:21:31 UTC+10, Egil H H  wrote:
> On Tuesday, September 18, 2018 at 1:54:37 PM UTC+2, rog...@iinet.net.au wrote:
> > The final three zeros above are an error in my report.
> 
> I don't think so. (11, 0, 0, 0) is most likely a 32-bit integer in little-endian format (interpreted as a byte array, with each byte printed in decimal), and all of it represents the string length (and since the length is specified, you should not assume a zero-terminated string)
> 
> 
> -- 
> ~egilhh

I meant the last three zeros of pcx0000 
That is:
The returned Assimp_Path is Length: 16, Data:  B000phoenix.pcx0

Re: Interface To C Struct That Includes An Array

[rakusu_klein]

вторник, 18 сентября 2018 г., 14:54:37 UTC+3 пользователь rog...@iinet.net.au написал:
> I agree but I don't know how to avoid it.
> Would pragma Convention (C, API_String) be OK?
> Also, I'm not sure that API_String is ever actually copied as all the interfacing is by pointers?
As ARM12 says, a records always passed to a C functions by reference in all modes other than an “in”. So if it does not a desirable behaviour, there are no reasons for this pragma and “pragma Convention (C, API_String)” would be clear and enough.

Btw, it is not helpful for your problem, sorry. There are nothing suspicious for me neither in your code, nor the Assimp code: https://code.woboq.org/qt5/qt3d/src/3rdparty/assimp/code/MaterialSystem.cpp.html#aiGetMaterialString Looks like the \x0B\x00\x00\x00phoenix.pcx\x00 sequence is the filename actually stored in aiMaterial. So, as you decided before, it would be better to look for input data.

Re: Interface To C Struct That Includes An Array

[rogermc]

On Wednesday, 19 September 2018 04:55:35 UTC+10, rakusu...@fastmail.jp  wrote:
> вторник, 18 сентября 2018 г., 14:54:37 UTC+3 пользователь rog...@iinet.net.au написал:
> > I agree but I don't know how to avoid it.
> > Would pragma Convention (C, API_String) be OK?
> > Also, I'm not sure that API_String is ever actually copied as all the interfacing is by pointers?
> As ARM12 says, a records always passed to a C functions by reference in all modes other than an “in”. So if it does not a desirable behaviour, there are no reasons for this pragma and “pragma Convention (C, API_String)” would be clear and enough.
> 
> Btw, it is not helpful for your problem, sorry. There are nothing suspicious for me neither in your code, nor the Assimp code: https://code.woboq.org/qt5/qt3d/src/3rdparty/assimp/code/MaterialSystem.cpp.html#aiGetMaterialString Looks like the \x0B\x00\x00\x00phoenix.pcx\x00 sequence is the filename actually stored in aiMaterial. So, as you decided before, it would be better to look for input data.

Thanks for your advice.
It definitely looks like my input data structure is incorrect so I'm working on fixing that up now.