Re: [Pyobjc-dev] Can't bridge UCConvertUTCDateTimeToCFAbsoluteTime

[Ronald O. <ron...@ma...>]

On 26 Nov, 2007, at 22:55, Ben Artin wrote:

>
> On Nov 26, 2007, at 3:17 PM, blake wrote:
>
>>> I am trying to bridge UCConvertUTCDateTimeToCFAbsoluteTime using
>>> PyObjC in Leopard.
>>>
>>> The problem that I am running into is that
>>> UCConvertUTCDateTimeToCFAbsoluteTime takes a struct that's declared
>>> (on 32 bits) as {unsigned short; unsigned long; unsigned short;}
>>> using
>>> packed alignment, which means that the offset of the 4-byte long
>>> member is 2. When I use {UTCDateTime=SLS}, PyObjC puts the 4-byte
>>> long
>>> at offset 4, which then causes problems down the line.
>>>
>>> Looking at PyObjC source, I don't see a way to force custom  
>>> alignment
>>> of struct members.
>>>
>>> Did I miss some mechanism for handling this? What are my option?
>>> Thanks,
>>
>> The problem appears to be that no metadata exists for <CarbonCore/
>> UTCUtils.h>. You might try running gen_bridge_metadata(1) on
>> CarbonCore.framework, or typecast UTCDateTime to int64_t instead.
>
> I believe you misunderstood my problem. I am trying to provide the
> bridge metadata myself, and I believe that it is *impossible* to
> provide appropriate bridge metadata because the metadata support as it
> exists right now does not allow bridging a struct that is aligned as
> UTCDateTime (obviously, without writing my own bridge function for
> UCConvertUTCDateTimeToCFAbsoluteTime -- if I write my own, I can do
> anything I want).
>
> Also, documentation for UTCDateTime specifically says that it's wrong
> to access it at uint64_t, so that advice is incorrect.

The advice is actually a good idea: just use 'Q' as the encoding for  
struct UTCDate and you're set as long as the definition of UTCDate  
doesn't change, and that's not likely to happen due to binary  
compatibility constrains.

That way you won't have to write C code to bridge this API.

Ronald