Georg Nikodym writes:
Charles correctly points out that there's a bug. I can't speak for
others but the reason that I've never seen it is because things like
alloc.c are getting stddef.h indirectly.
<snip>
I'm running something a little more modern than 2.5.1 but looking at
one here I see that /usr/openwin/include/X11/Xlib.h includes stddef.h
directly.
So it's likely that the real source of Charles' pain lies somewhere in
what he's using as a windowing system.
It's not exactly "pain"[1], it's a very minor glitch. I just added a
few "#include <stddef.h>"'s in a few of the source files (alloc.c,
malloc.c, and unexec.c) and XEmacs builds and runs just fine[2]
Should these #includes just get patched into the source, or
should it be taken care of by "configure"?
The windowing system in question is the version of CDE that came with
Solaris 2.5. It has a /usr/openwin/include/X11/Xlib.h that reads like
this:
#ifndef X_WCHAR
#include <stddef.h>
#else
/* replace this with #include or typedef appropriate for your system */
typedef unsigned long wchar_t;
#endif
That is the only occurence of "stddef.h" in Xlib.h. So I suppose I
have X_WCHAR getting defined from somewhere else, and that's keeping
stddef.h from being indirectly included.
But it seems that files that use "ptrdiff_t" should not be counting on
some kind of indirect inclusion of stddef.h, they should just go ahead
and include it.
Footnotes:
[1] Real pain is trying to get subprocesses working on Win32!
[2] although it's slow as molasses on this SparcStation4, compared
to the dual-Pentium system I use most of the time...