Re: feature request for setting _pack_ to a higher value

Am 22.03.2010 um 21:56 schrieb Mads Kiilerich:

> Axel Seibert wrote, On 03/22/2010 07:58 AM:
>> Hi, Mads, dear list!
>> 
>>   
>>> Can you give an (or several) exact example of a problematic C
>>> declaration and what you would have hoped worked with ctypes and how you
>>> have to workaround?
>>>     
>> 
>> I don't think I expected some magic bullet from ctypes, I just had not expected so many problems when changing from Windows to Linux. And, ctypes already has already in there that I need -- there is just one check within ctypes that makes my workaround currently impossible.
>> 
>> This is an excerpt from the python that the code generation created for me from the header file. They are the same under windows&  linux.
>>   
> 
> FWIW I think you would help yourself by also posting or referring to the exact corresponding C declaration and references to exactly which version of which tool you have used and how you invoked it.
> 
> gcc on linux compiles the structs "correctly" with 8 bytes alignment? Where do that alignment come from?

If you mean "gcc compiled the structs" as in "the C compiler gcc under Linux compiled C sources using the structs with 8 bytes alignment" -- then I have no idea, as I'm not developing in C.
If you mean the gccxml compiler generated 8 bytes alignment -- then no, there was  an error in the first version that I posted, where - by accident -- I left the _pack_ = 8 in.


So, let me try to explain this maybe in some other words; I have this third party application library that supplies me with one or more header files. When I compile those with h2xml -> xml2py (using gccxml), I get the following resulting python code (and a coupleof other 1000 lines more):
STRING = c_char_p
ARLong32 = c_long
ARULong32 = c_ulong
ARTimestamp = ARLong32
ARTime = ARLong32

class ARValueStruct(Structure):
  pass
class N13ARValueStruct3DOT_1E(Union):
  pass
N13ARValueStruct3DOT_1E._fields_ = [
  ('noval_', size_t),
  ('keyNum', c_uint),
  ('intVal', ARLong32),
  ('realVal', c_double),
  ('charVal', STRING),
  ('diaryVal', STRING),
  ('enumVal', ARULong32),
  ('timeVal', ARTimestamp),
  ('maskVal', ARULong32),
  ('timeOfDayVal', ARTime),
  ('byteListVal', POINTER(ARByteList)),
  ('decimalVal', STRING),
  ('attachVal', POINTER(ARAttachStruct)),
  ('ulongVal', ARULong32),
  ('coordListVal', POINTER(ARCoordList)),
  ('dateVal', c_int),
  ('currencyVal', POINTER(ARCurrencyStruct)),
  ('ptrVal', c_void_p),
]
ARValueStruct._fields_ = [
  ('dataType', c_uint),
  ('u', N13ARValueStruct3DOT_1E),
]

When I use this in calling the library functions under Windows & Solaris everything works.
When I use this in calling the library functions under Linux, I get completely unexpected results and crashes.

An older version of xml2py (from 2005) not only generated the python C types, but also two asserts for each of them: one to check the size of the struct, and one to check the alignment. Running those checks over the structures under Linux, revealed that for 44 of roughly 400 Structs, the default alignment under Linux did not match that of Windows or Solaris (please remember, everything using 32bit).
Setting _pack_ = 8 at those 44 Structs resolved the issue -- no more unexpected results or crashes.
The only thing is that I needed to patch file cfield.c in one single line of source code to enable setting _pack_ to a higher value than the platform default.

I hope I could describe it clearer this time.

Thanx for your patience,
Axel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev