Re: [Hessianobjc-user] encoding NSDecimalNumber

[Byron W. <by...@bl...>]

Tore,

after following the cocoa thread about this I implemented  
BBSHessianEncoder using the CFSwap and CFConvert functions instead of  
the Endian ones. My units tests were successful so I checked my  
latest into svn. Please let me know if there are any issues on Intel  
ASAP, I believe they should now be resolved.

Cheers,
Byron

On Oct 8, 2006, at 4:47 PM, Tore Halset wrote:

> On Oct 9, 2006, at 01:26, Byron Wright wrote:
>
>> As you can see testDecimal is 23.0. In BBSHessianEncoder  - (void)  
>> encodeNumber:(NSNumber *) aNumber , I compare the underlying  
>> objCType to determine what kind of number this is and encode  
>> accordingly. For NSDecimalNumber this should always  'd' and  
>> should therefore get encoded using - (void) encodeDouble:(double)  
>> aDouble. So something (perhaps an Endian issue) might be going  
>> wrong there. Perhaps you could debug this and tell me what the  
>> character for this is [aNumber objCType] when using  
>> NSDecimalNumber (it should be 'd'). It's a little difficult to  
>> test endian issues without an intel mac :(
>
>
> I entered "12.25" this time to be able to compare to the example at  
> http://www.caucho.com/resin-3.0/protocols/hessian-1.0-spec.xtp#double
>
> I added the following debug-NSLog to the start of encodeNumber:
> NSLog(@"encodeNumber. objCType: %s, value: %@", [aNumber objCType],  
> aNumber);
> It wrote the following line:
> encodeNumber. objCType: d, value: 12.25
>
> The value sent over the wire to the server is "4400 0000 0000 00a8  
> 43" where "44" is "D" for Double.
>
> Looks like a powerpc contra intel bug not related to endian. I'll  
> let you know if I find a solution...
>
>  - Tore.
>