The Debian package has accumulated a few patches through the years. Could you perhaps consider applying some of them?
https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/bad_size_t_r... Fix undefined behaviour/buffer overruns on 64-bit architectures caused by broken redefinition of size_t. Basically the same change as was made to image_jpeg.c in 2008.
https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/undefined_ht... Protocols.DNS_SD apparently doesn't include the necessary header declaring htons() (arpa/inet.h *or* netinet/in.h depending on platform). The code might compile anyway, but crash later.
The rest are actually all HURD related, but should be harmless enough:
https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/pthread_stub... Check whether pthread_atfork() is a stub and not just whether it exists.
https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/misplaced_MA... The conditional #define MAXPATHLEN comes after the first use of it (in src/modules/_Stdio/efuns.c).
https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/hurd.patch?r... 1. Let realpath() allocate memory itself. 2. Include mach/message.h directly where mach_msg_type_number_t is used. 3. Don't build shared objects any differently than on Linux (-shared, not -Wl,-Bshareable).
https://anonscm.debian.org/viewvc/pkg-pike/trunk/debian/patches/hurd.patch?r...
- Let realpath() allocate memory itself.
This one should probably use a configure test instead of relying on preprocessor symbols.
Perhaps, but what do we want to check for? __GNU__ is quite well-defined to mean GNU Hurd, I believe. We could simply check if PATH_MAX is undefined instead, or _always_ call realpath() with NULL second argument, to not have to bother with PATH_MAX regardless of platform, as per POSIX.1-2008. Though I don't know about Windows.
Well, I guess it's not unusual to try compiling and running a test program, even if it might segfault. The AIX documentation actually doesn't seem to mention a NULL second argument.
pike-devel@lists.lysator.liu.se