Re: GNU M4 1.4.8b released (beta release)

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

> 
>>   - 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).

> 
> 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.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7CYN84KuGfSFAYARAjO+AJ46Doiy2s1XsbSW/jfsXMlpsFGyFwCfX/DD
Z5yVe/O6LQzoVu/kfpM5u7w=
=oAU2
-----END PGP SIGNATURE-----