K> I got the following error when I tried to make 21.0.65 on my DU 4.0D K> system: K> cc -c -std -fast -Demacs -I. -DHAVE_CONFIG_H -std -I/usr/local/include -I/usr/dt/include abbrev.c K> cc: Error: lisp.h, line 2451: Ill-formed parameter type list. K> int unexec (char *, char *, uintptr_t, uintptr_t, uintptr_t); K> ----------------------------^ K> gmake[1]: *** [abbrev.o] Error 1 K> gmake[1]: Leaving directory `/home/oberman/utils/xemacs-21.0.65/src' K> gmake: *** [src] Error 2 K> Configured using: K> ./configure --with-site-lisp --site-includes=/usr/local/include --without-gcc --with-gnu-make '--cflags=-std -fast' Sorry, this works for me on DU 4.0E. Please figure out why uintptr_t is not defined. There's code in lisp.h to make sure it is. Martin

K> I got the following error when I tried to make 21.0.65 on my DU 4.0D K> system: K> cc -c -std -fast -Demacs -I. -DHAVE_CONFIG_H -std -I/usr/local/include -I/usr/dt/include abbrev.c K> cc: Error: lisp.h, line 2451: Ill-formed parameter type list. K> int unexec (char *, char *, uintptr_t, uintptr_t, uintptr_t); K> ----------------------------^ K> gmake[1]: *** [abbrev.o] Error 1 K> gmake[1]: Leaving directory `/home/oberman/utils/xemacs-21.0.65/src' K> gmake: *** [src] Error 2 K> Configured using: K> ./configure --with-site-lisp --site-includes=/usr/local/include --without-gcc --with-gnu-make '--cflags=-std -fast' >> Sorry, this works for me on DU 4.0E. >> Please figure out why uintptr_t is not defined. >> There's code in lisp.h to make sure it is. Kev> Yes, but it looks like a bug in the inttypes.h on DU4.0D when IPv6 is Kev> installed. The problem is that IPv6 adds the file Kev> "/usr/include/inttypes.h" which previously did not exist. lisp.h Kev> includes this inttypes.h which just defines _INTTYPES_H and includes Kev> sys/inttypes.h. But sys/inttypes.h only defines uintptr_t when Kev> _INTTYPES_H is NOT defined, so it does nothing. Since inttypes.h is still undergoing standardization, it seems to be causing more problems than it solves. I propose that we stop using it. (I was the one who (mistakenly?) introduced it). We have to have our own code anyways to define intptr_t and friends, which works pretty darn well. In the real world, sizeof(void*) will always be equal to sizeof(int) or sizeof(long). Currently lisp.h has: #ifdef HAVE_INTTYPES_H #include <inttypes.h> #elif SIZEOF_VOID_P == SIZEOF_INT typedef int intptr_t; typedef unsigned int uintptr_t; #elif SIZEOF_VOID_P == SIZEOF_LONG typedef long intptr_t; typedef unsigned long uintptr_t; #elif defined(SIZEOF_LONG_LONG) && SIZEOF_VOID_P == SIZEOF_LONG_LONG typedef long long intptr_t; typedef unsigned long long uintptr_t; #else /* Just pray. May break, may not. */ typedef long intptr_t; typedef unsigned long uintptr_t; #endif Kev> I assume that this is an error as I don't think this behavior is Kev> reasonable. I worked around it by changing lisp.h to include Kev> sys/inttypes.h and this did the trick. I will contact the IPv6 folks Kev> at Compaq and see if there is a fix (or I may just do it myself). Kev> Since so few people are likely to have IPv6 installed and since it Kev> appears to clearly be a bug in the IPv6 supplied file, I don't see any Kev> reason to "fix" anything, but a caveat might be in order. (Though I'm Kev> not too sure it's worth even that.) Again, I propose we stop #including <inttypes.h> Comments? Martin

I'm not so sure of that. As we move more toward 64 bit systems, always may only be a couple of years. Depends on how vendors implement this. If my case (which is very odd and clearly a bug in the IPv6 code) is the only one reported, I don't think that justifies pulling the use of what will hopefully become the standard way of dealing with different integer sizes. Of course, if there are others seeing the problem... R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634