Re: GNU M4 1.4.8b released (beta release)

[Eric Blake]

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

According to Eric Blake on 3/5/2007 7:15 AM:
> 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).

I'd really like some feedback on this thread.  It is the only issue
holding up a release of M4 1.4.9.

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

iD8DBQFF8BNv84KuGfSFAYARAmgPAJ4+jog4UCUU6Kp/mjQS6zRmCijILQCfXtO8
cbyb95CvsNEpuo8FnEsTjn0=
=ckRs
-----END PGP SIGNATURE-----