>>>> "R" == Robert Pluim
<rpluim(a)bigfoot.com> writes:
R> Martin Buchholz writes:
> The patchlet below contains FreeBSD-specific hacks. You just
know
> this isn't going to really fix the problem, since it will re-occur on
> FooBSD and random other OSes.
R> Yes. I never claimed to be proud of it.
Neither am I proud of being partially responsible for this mess.
> What to do? I've known for a while that there's a
problem with
> XEmacs' attempt to use the new semi-standard fixed-size integral types
> like uint8_t and Berkeley DB's attempt to do the same. A real fix is
> going to involve looking at all of the Berkeley DB version's code for
> detecting these types and coordinating with our own.
>
> In retrospect, it was a mistake (mine) for XEmacs to detect and use
> inttypes.h. This header file never became part of a standard (instead
> stdint.h did) and implementation of these header files has been
> inconsistent and slow. C99 has stdint.h, but C++97 does not. I've
> not yet heard of any C compiler advertising complete C99 compliance.
>
> Anyways, a proper fix is going to involve research, deep thought and
> careful testing on multiple platforms. The below is the sort of
> bandaid that I've been careful to avoid during my time as
> configuration maintainer.
R> Would it be worthwhile to start by getting rid of our use of
R> inttypes.h? That's easy enough for me to test.
You could try:
removing all references to inttypes.h.
trying to remove those horrible hacks referring to
__BIT_TYPES_DEFINED__ and WE_DONT_NEED_QUADS
However, doing this is quite risky in a stable XEmacs. XEmacs may
fail to compile on some other platform. On the other hand, if it does
compile, it will work perfectly.
This is really my area of expertise, so I should be fixing it. But I
don't have a lot of free time right now.
Martin