Re: GNU M4 1.4.8b released (beta release)

[Matthew Woehlke]

Eric Blake wrote:
> According to Matthew Woehlke on 3/2/2007 9:33 AM:
> > > Another option would be to leave int64_t defined as it is, but set
> > > HAVE_INT64_T
> > > to 0, to indicate that gnulib shouldn't use it.
> > Hmm... this looks like it would fix sys/stat.h (see below). I'm still
> > not sure I trust it. Will clock_t and fpos_t be defined correctly so as
> > to not break system API's using these? Will gnulib behave correctly
> > w.r.t. these?
>
> We don't have access to your system, so you will have to try various
> experiments.  One thing that would be helpful is for you to determine how
> packages will behave as though the .m4 files were fixed to already
> recognize that gnulib's assumptions about long long are broken, and
> therefore, from gnulib's point of view, a working long long does not exist
> (leaving actual system headers to use long long to their hearts content,
> unmolested by gnulib's replacement stdint.h).
>
> Can you try 'ac_cv_type_long_long_int=no
> ac_cv_type_unsigned_long_long_int=no ac_cv_type_long_long=no ./configure'
> and see if that can build a working image?

(We already know this doesn't work: if configure doesn't define 
HAVE_LONG_LONG_INT, then the resulting stdint.h breaks system headers.)

> > >   - what is the original definition of int64_t on this OS if gnulib is
> > > not involved? (a macro, a typedef?)
> > sys/types.h has:
> >
> > #ifdef __TANDEM
> > #define int64_t long long
> > #else
> > typedef double  int64_t;
> > #endif
> >
> > (__TANDEM is normally defined; the alternative is clearly a hack of sorts.)
>
> So this part of stdint_.h could use an edit to not unconditionally
> undefine int64_t:
>
> #undef int64_t
> #if LONG_MAX >> 31 >> 31 == 1
> # define int64_t long int
> #elif defined _MSC_VER
> # define int64_t __int64
> #elif @HAVE_LONG_LONG_INT@
> # define int64_t long long int
> #endif
>
> instead, it should look like
>
> #if LONG_MAX >> 31 >> 31 == 1
> # undef int64_t
> # define int64_t long int
> #elif defined _MSC_VER
> # undef int64_t
> # define int64_t __int64
> #elif @HAVE_LONG_LONG_INT@
> # undef int64_t
> # define int64_t long long int
> #endif
>
> Can you test (preferably independently of the earlier test) whether that
> edit helps matters any?  There may be further edits necessary, since later
> parts of stdint_.h currently depend on whether int64_t is defined, when
> they should really depend on whether int64_t is defined by gnulib (since
> you've already proven that it is defined by your platform, but that gnulib
> doesn't really work with 64-bit types on your platform).

Without also telling gnulib not to use 'long long', we know other things 
(like gnulib's printf - of whichever flavor, I don't recall exactly 
which one offhand) break.

I did this:

--- stdint_.h   2007-03-08 08:14:55.000000000 -0800
+++ ../../m4-1.4.8b-orig/lib/stdint_.h  2007-03-01 08:48:39.000000000 -0800
@@ -120,17 +120,12 @@
 #define int32_t int
 #define uint32_t unsigned int

+#undef int64_t
 #if LONG_MAX >> 31 >> 31 == 1
-# undef int64_t
-# define GNULIB_int64_t
 # define int64_t long int
 #elif defined _MSC_VER
-# undef int64_t
-# define GNULIB_int64_t
 # define int64_t __int64
 #elif @HAVE_LONG_LONG_INT@
-# undef int64_t
-# define GNULIB_int64_t
 # define int64_t long long int
 #endif

@@ -169,10 +164,10 @@
 #define uint_least16_t uint16_t
 #define int_least32_t int32_t
 #define uint_least32_t uint32_t
-#ifdef GNULIB_int64_t
+#ifdef int64_t
 # define int_least64_t int64_t
 #endif
-#ifdef GNULIB_uint64_t
+#ifdef uint64_t
 # define uint_least64_t uint64_t
 #endif

@@ -200,7 +195,7 @@
 #define uint_fast16_t unsigned int_fast16_t
 #define int_fast32_t long int
 #define uint_fast32_t unsigned int_fast32_t
-#ifdef GNULIB_int64_t
+#ifdef int64_t
 # define int_fast64_t int64_t
 #endif
 #ifdef uint64_t
@@ -222,7 +217,7 @@
 #undef intmax_t
 #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
 # define intmax_t long long int
-#elif defined GNULIB_int64_t
+#elif defined int64_t
 # define intmax_t int64_t
 #else
 # define intmax_t long int
@@ -269,7 +264,7 @@

 #undef INT64_MIN
 #undef INT64_MAX
-#ifdef GNULIB_int64_t
+#ifdef int64_t
 # define INT64_MIN  (~ INT64_MAX)
 # define INT64_MAX  INTMAX_C (9223372036854775807)
 #endif
@@ -308,7 +303,7 @@

 #undef INT_LEAST64_MIN
 #undef INT_LEAST64_MAX
-#ifdef GNULIB_int64_t
+#ifdef int64_t
 # define INT_LEAST64_MIN  INT64_MIN
 # define INT_LEAST64_MAX  INT64_MAX
 #endif
@@ -347,7 +342,7 @@

 #undef INT_FAST64_MIN
 #undef INT_FAST64_MAX
-#ifdef GNULIB_int64_t
+#ifdef int64_t
 # define INT_FAST64_MIN  INT64_MIN
 # define INT_FAST64_MAX  INT64_MAX
 #endif
@@ -474,7 +469,7 @@
 #undef INTMAX_C
 #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
 # define INTMAX_C(x)   x##LL
-#elif defined GNULIB_int64_t
+#elif defined int64_t
 # define INTMAX_C(x)   INT64_C(x)
 #else
 # define INTMAX_C(x)   x##L

...and I'm waiting to see if it works (did I mention this box is 
god-awful slow? :-)).

> > Oh, and clock_t, dev_t and fpos_t are also 'long long', and 'long long'
> > shows up in several places in socket code (not sure if that's an issue
> > or not, since so far we aren't talking about any networking apps).
>
> Shouldn't matter - gnulib can't redefine 'long long' since it occupies
> multiple tokens; and as long as gnulib doesn't use long long, we shouldn't
> be running afoul of your compiler's (awful) limitations.

The question was "does gnulib ever use clock_t, dev_t or fpos_t?", 
particularly in reference to system headers.

--
Matthew
"There's nothing in the universe so permanent as a temporary government 
agency." -- Phil Geusz