cracked it! (cleaning up)

I searched on ssize_t.

There are 5 files where ssize_t is defined:
configure.in //irrelevant to win32
config.w32.h //changed definition to #define ssize_t SSIZE_T because
<windows.h> is more pervasive in the upper reaches of PHP than
<stddef.h>
fcgi_config_win32.h //removed the define, no longer needed
fcgi_config_x86.h //irrelevant to win32
php_mnogo.c //irrelevant to win32

There are 3 files where <stddef.h> is included:
snprintf.c //removed the include line, no longer needed
spprintf.c //needs stddef.h, uses ptrdiff_t
cast.c //removed the include line, no longer needed

There is one file (Sterling's, naturally) where win32 isn't a
consideration:
dio.c //irrelevant to win32

and one file where win32 is irrelevant given the context
(because PHP_PREAD_64 is only defined in acinclude.m4)
php.h //irrelevant to win32

and then there's our friend the gd-breaker:
gd_jpeg.c //removed the ssize_t define, no longer needed

Now we don't HAVE to make those changes, but if we do, it's better
future-proofing for that particular typedef because it provides a more
generic solution than the one currently in place.

G'night!!

This is not correct, both use ptrdiff_t.

Yes. One already has an include that defines it.. OK OK, agreed that's
tenuous.

Also you need the sizeof define (which works as a detection define,
too):
SIZEOF_PTRDIFF_T

This is defined as an absolute in config.w32.h (for 32-bit and 64-bit
architectures).

Generally your analyse looks good besides the comment above.
Only i am not sure if we can really nuke the include, you sure about
that?

Definitely cast.c. Everything builds if you nuke it on snprintf.c too.
If anyone can mail me/point me to a test script that will check
either/both contentions, I have that build sitting here at present..

However changing the define to the one you suggest might be a good
idea.

thx ;)

• Steph