Re: Casting int <--> double and signs
- Posted by mattlewis (admin) Jul 17, 2013
- 1415 views
When using a pointer (in the back end or translated) it will be cast to a pointer type, and it's interpreted as unsigned. I suppose we could return it as a signed value, which on 32-bits would keep more pointers as integers, but this seems like a bad idea.
Maybe I'm misunderstanding, but all pointers in the back end are signed types (object is typedef'd to intptr_t) so that it can be determined if it is an integer, atom, or sequence.
I agree that it should be returned to the user as an unsigned pointer; but that users should be allowed to use signed pointers as arguments if they want. That's what I meant -- we should assume that addresses are uints for output back to the user, but we should accept either uints or signed ints FROM the user. Maybe they got a signed value from an expression? I don't know.
I guess what I mean is that the policy should be that the user shouldn't have to worry about signed vs. unsigned unless they want to do so.
An object isn't a pointer (I'm talking about the C code now). Whatever its value is, before we use it as a pointer in C code, it gets cast to some pointer type. I don't see anything about what you said users should be able to do that shouldn't work in practice, assuming you got pointers that had a negative representation as a signed integer. Definitely won't happen in 64-bit. Not sure how often that might happen in 32-bit.
We have signed and unsigned versions of peek. Pokes don't matter. What sort of bounds checking? Something beyond what std/safe.e does?
I'm not sure what safe.e does. I'll have to go look. What happens if you do
poke2u(addr, -16380) poke2s(addr, 60956)
Do you get an error, or does it convert signed<-->unsigned silently?
That would give you an error, since there are no such things as poke2u or poke2s. Just poke2. Yes, it's converted automatically for you. But you could do the following:
include std/machine.e atom addr = allocate( 100 ) poke2(addr, -16380) ? peek2u( addr ) -- 49156 poke2(addr, 60956) ? peek2s( addr ) -- -4580 free( addr )
Thanks, that actually makes sense thinking about it. Was 'i' originally declared as an integer? Because it is declared an atom now.
It probably was an integer originally. But this has obvious problems if you're translating 64-bit code with a 32-bit translator, which I think is why it was changed.
As I think about this, does it make more sense to be one of
i < TMAXINT/16 -- leave room for one more digit -- equivalent to i <= TMAXINT/32? --snip-- if i>= TMAXINT then is_int = FALSE
Or is that still subject to overflow?
Regardless, it seems to work as-is.
I try not to think too hard about this, because I usually come up with the wrong answer, so I test it out. 
Matt
