2009/2/1 Gabriel Dos Reis <gdr@integrable-solutions.net>
On Sun, Feb 1, 2009 at 6:52 PM, Geo Carncross <geocar@gmail.com> wrote:
> On Sun, Feb 1, 2009 at 3:50 PM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>>
>>   (int)(intptr_t)file
>>
>> since intptr_t is garanteed to be precise enough to hold
>> a value of type void*.
>
> Well, casting it to (int) [if that causes problems] would simply truncate it
> again anyway- even though it was originally cast to intptr_t
>

In earlier conversation, Juanjo seemed to suggest that
the value there really was an int. So the truncation was OK.
My point in my preceding message is that the mapping
from void* to int is highly unportable (anyone to guess standard
semantics?), compared to the mapping from void* to intptr_t,
which although implementation-defined is guaranteed to yield
the original int value back.

That's true. I couldn't find where you were talking about in c/file.d - I just saw all the FILE* packs into that file. field (and back again) and assumed it was one of those.
 

My personal inclination would be to use a union of void* and int,
and select the appropriate field, thereby not depending on any
implementation defined assumption at all.  That also would
make the intent clearer.

I agree, but it seems like a lot of the stdio code is getting ripped out in favor of posixish reads and writes which means it might really become an int soon :)