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

[blake <ch...@ap...>]

On Nov 27, 2007, at 11:31 AM, Ronald Oussoren wrote:

>
> On 27 Nov, 2007, at 20:08, blake wrote:
>
>>
>> On Nov 27, 2007, at 5:16 AM, Ben Artin wrote:
>>
>>>
>>> On Nov 27, 2007, at 1:07 AM, Ronald Oussoren wrote:
>>>
>>>>
>>>> On 26 Nov, 2007, at 22:55, Ben Artin wrote:
>>>>
>>>>>
>>>>> On Nov 26, 2007, at 3:17 PM, blake wrote:
>>>>>
>>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>> I guess carrying it across the bridge as a uint64_t is OK as long as
>>> I don't try to do math with it as an integer? Thanks.
>>>
>>
>> I was thinking that a scalar type would be safe for bridge
>> travel(assuming no math expressions) But after rereading the docs, I
>> would recommend testing that solution on both ppc and x86 to be safe.
>
> sizeof(UTCDateTime) is 8 on ppc, x86 and x86_64 (I cannot test on  
> ppc64), so it should be safe to bridge it as a int64_t value.  The  
> value is be a magic cookie (that is doing math on it would give  
> nonsensical results), but otherwise this should work just fine.
>

I was more worried about endianness than size- there may be no  
problem, but someone should verify that.