4:22 p.m.
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.
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.
2003-03-03 Robert Pluim <rpluim(a)bigfoot.com>
* database.c: Don't use the u_int8_t etc typedefs on FreeBSD,
they conflict with <sys/types.h>.
Index: database.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/database.c,v
retrieving revision 1.16.2.2
diff -u -r1.16.2.2 database.c
--- database.c 2003/02/24 03:25:24 1.16.2.2
+++ database.c 2003/03/03 09:07:51
＠＠ -45,11 +45,13 ＠＠
#ifdef HAVE_INTTYPES_H
#define __BIT_TYPES_DEFINED__
#include <inttypes.h>
+#ifndef __FreeBSD__
typedef uint8_t u_int8_t;
typedef uint16_t u_int16_t;
typedef uint32_t u_int32_t;
#ifdef WE_DONT_NEED_QUADS
typedef uint64_t u_int64_t;
+#endif
#endif /* WE_DONT_NEED_QUADS */
#endif /* HAVE_INTTYPES_H */
#endif /* !(defined __GLIBC__ && __GLIBC_MINOR__ >= 1) */
4:40 p.m.
On Sun, 9 Mar 2003, Martin Buchholz wrote:
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.
I see the same errors/warnings under Mac OS X which is based on FreeBSD.
r. royar
8:47 p.m.
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.
Yes. I never claimed to be proud of it.
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.
Would it be worthwhile to start by getting rid of our use of
inttypes.h? That's easy enough for me to test.
Robert
--
10:05 p.m.
>>>> "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
10:50 p.m.
Martin Buchholz writes:
>>>>> "R" == Robert Pluim
<rpluim(a)bigfoot.com> writes:
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.
I only have access to FreeBSD at the moment (and Linux, but that
requires some work on my part first). Perhaps we should target this
effort at 21.5?
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.
Ditto. The new-born comes home day after tomorrow, so I'm likely to
be maxed out for the next 18 years or so ;-)
Robert
--
12:48 p.m.
Ar an 9ú lá de mí 3, scríobh Martin Buchholz :
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.
All the information I've seen on C99 says that it includes <inttypes.h>;
this includes the final committee draft of the standard (not the standard
itself, admittedly), http://www.dinkumware.com/htm_cl/inttypes.html , and
various newsgroup postings from people who Should Know. If you have a copy
of the standard itself, fair enough, but if not, do you have any reference
for it not being there?
(Yes, it would be nice if more of the OS implementors cleared this area up.)
--
"I have heard the swelling cry of the English speaking peoples of the
world, and it tells me their cause is served best by flaming the few
complacent asses on usenet." -- T. Samant, 29 June 1997
2:59 p.m.
>>>> "AK" == Aidan Kehoe
<kehoea(a)parhasard.net> writes:
AK> Ar an 9ú lá de mí 3, scríobh Martin Buchholz :
> 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.
AK> All the information I've seen on C99 says that it includes <inttypes.h>;
AK> this includes the final committee draft of the standard (not the standard
AK> itself, admittedly), http://www.dinkumware.com/htm_cl/inttypes.html , and
AK> various newsgroup postings from people who Should Know. If you have a copy
AK> of the standard itself, fair enough, but if not, do you have any reference
AK> for it not being there?
AK> (Yes, it would be nice if more of the OS implementors cleared this area up.)
I stand semi-corrected. I don't have the actual standard myself
either, but I now believe it refers to both stdint.h and inttypes.h.
In this message:
http://mail.gnu.org/archive/html/autoconf/2001-12/msg00032.html
Paul Eggert (who is very reliable) claims:
----------------------------------------------------------------
So, perhaps we should just include <stdint.h> and forget about
<inttypes.h>?
No, because:
Are there platforms that have <inttypes.h> but not
<stdint.h>?
Yes. Solaris 8, for example.
In my experience, <inttypes.h> is a bit more reliable than <stdint.h>
because it has been around longer. <stdint.h> is a creation of the
C99 committee, whereas <inttypes.h> exists on many pre-C99 platforms.
C99 says that freestanding C99 platforms must have <stdint.h> but may
lack <inttypes.h>, which is the only reason I'd worry about <stdint.h>
at all. I've never used such a platform, but I wouldn't be surprised
to come across one someday.
my guess is that turning off autoconf's use of <inttypes.h>
and
<stdint.h> durign configuration, and then dropping them from our
created include file, would be a good solution -- if we can easily
convince autoconf that's what we want to do.
OK, but I would suppress <inttypes.h> and/or <stdint.h> only if you
detect the header incompatibility. I think this will give you better
results on future platforms. On some platforms, for example, I
wouldn't be surprised if intmax_t is wider than long long.
----------------------------------------------------------------
Martin
7928
days inactive
7929
days old
6 comments
4 participants
participants (4)
-
Aidan Kehoe -
Martin Buchholz -
robert delius royar -
Robert Pluim