> What about
>
> #define ssize_t INT_PTR
>
> for Win{32|64} ??
>
> --
> Ard
SSIZE_T is already an INT_PTR in both architectures. Calling it INT_PTR
directly, doesn't actually change anything from the current php-src (the
patch Edin put in for me yesterday). The objection Wez made to that was
th
Steph wrote:
... except that INT_PTR is 64-bit on Win64, and int is not.
yeah, I just found that too :)
This means that php-src is currently correct for all architectures but fcgi
src is not. So what's the best line of attack here?
What about
#define ssize_t INT_PTR
for Win{32|64} ??
--
Ard
-
> ... except that INT_PTR is 64-bit on Win64, and int is not.
>
yeah, I just found that too :)
This means that php-src is currently correct for all architectures but fcgi
src is not. So what's the best line of attack here?
#ifdef _WIN64
+ # define ssize_t SSIZE_T
# define SIZEOF_SIZE_T 8
# defi
Steph,
Windows - uniquely - uses the definition SSIZE_T (type: INT_PTR) - note
that ssize_t isn't the same thing as SSIZE_T, anywhere - but if I go that
route for ssize_t definition (as I already tried to do) we end up with the
fcgi redefinition to int anyway.
Basically all I'm doing here is goin
[mailto:[EMAIL PROTECTED]
> Sent: 14 November 2003 11:17
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Re: PATCH ssize_t without messing with fcgi source
>
>
> > Works with everything. (phew!)
> >
>
> You might wanna use long instead of
Steph wrote:
Works with everything. (phew!)
Are you sure this will work on Win64 ?
I think sizeof(ssize_t) is supposed to match the native pointer size.
--
Ard
Index: main/config.w32.h
===
Works with everything. (phew!)
You might wanna use long instead of int here, as sizeof(ssize_t) is
supposed to match the native pointer size.
--
Ard
Index: main/config.w32.h
=
