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

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

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.

Ronald
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev