Yang Tse wrote:
> I can see the following...
>
> #if defined(_WIN64)
> typedef __int64 INT_PTR, *PINT_PTR;
> [...]
> typedef __int64 LONG_PTR, *PLONG_PTR;
> [...]
> #else
> typedef _W64 int INT_PTR, *PINT_PTR;
> [...]
> typedef _W64 long LONG_PTR, *PLONG_PTR;
> [...]
> #endif
>
> So I insist that for this example anyauthput.c, the only place in the
> whole curl source tree where intptr_t is used, the appropriate
> replacement to use is INT_PTR and not LONG_PTR. Even when long and int
> happen to have the same size here they are different data types.

Since you're hiding it behind the name intptr_t, it really doesn't
matter which you use in the typedef, except on 16-bit Windows.

Traditionally in unix, it's been permitted to convert a data pointer
to "long" and back, which is why so much code does that, and why in
Windows you'd be encourage to substitute LONG_PTR instead.

It's never been particularly traditional to convert to "int" and back.

Modern code should use intptr_t or uintptr_t, since they are standard.
On Windows define intptr_t as LONG_PTR or INT_PTR (doesn't matter on
32/64-bit Windows), and on unix, if there isn't a header defining
them, define them to long and unsigned long respectively.

> File descriptor data type is int for _lseek(), _read(), _fstat(),
> _close() as well as the one returned from _open(). So why should we
> use LONG_PTR instead of INT_PTR ?

Is there any connection at all between file descriptors and pointers?

-- Jamie
Received on 2008-09-02