Re: [pure-lang-users] C float

[Eddie R. <er...@bm...>]

On Wed, 2008-08-13 at 23:34 +0200, Albert Graef wrote:

> Under all circumstances, the C interface should behave as if the C int 
> type is "cast" to the Pure int type and vice versa (using truncation and 
> sign extension as necessary), if that's not the case then please report 
> it and I will fix it. I think that this is the most reasonable way to 
> implement the marshalling of C ints considering the limited repertoire 
> of integer types available in Pure.

I don't know yet. If it doesn't cause any problems then we should leave it alone.

> Of course, this means that a C unsigned int return value will become 
> negative in Pure if it's big enough. But that can be easily undone with 
> the following little Pure function which takes a Pure int x and returns 
> a bigint equal to (unsigned)x in C:
> 
> uint x::int = if x>=0 then bigint x else x+0x100000000L;
> 
> This carries over to unsigned 8, 16 and 64 bit ints accordingly:
> 
> ubyte x::int = if x>=0 then x else x+0x100;
> ushort x::int = if x>=0 then x else x+0x10000;
> ulong x::bigint = if x>=0 then x else x+0x10000000000000000L;
> 
> These always use the smallest Pure int type capable of holding the 
> result: int for ubyte and ushort, bigint for uint and ulong. (Note that 
> in the case of 64 bit values the C interface returns a bigint, that's 
> why ulong takes a bigint parameter.)
> 
> Maybe I should add those definitions to primitives.pure?

Maybe. My concern was mostly the parameters to a C function in a library
where one of the arguments was an unsigned int. We certainly cannot pass
a bigint can we? I know we can treat a signed int or unsigned the same
and I don't see it as much of a problem. I just get a bad feeling when
arithmetic is involved on a parameter during the call. I don't know
maybe I shouldn't be so concerned.

e.r.