> 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
Ard, hi -
ssize_t was originally defined as ptrdiff_t in config.w32.h, which is itself
defined as int in win32 (in stddef.h). It was then redefined as int in the
fcgi configuration. It was also redefined in gd_jpeg.c (one of the few
win32-affecting places that uses it) prior to any includes:
#i
