# cracked it! (cleaning up)

- Thread: https://externals.io/message/5002
- Original archive: https://news-web.php.net/php.internals/5002
- Started by Steph on 2003-10-26T05:11:39+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #5002 — Steph — 2003-10-26T05:11:39+00:00

URL: https://externals.io/message/5002#5002

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!!

---

## #5009 — Steph — 2003-10-26T14:47:05+00:00

URL: https://externals.io/message/5002#5009

> 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