autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU M4 1.4.8b released (beta release)


From: Eric Blake
Subject: Re: GNU M4 1.4.8b released (beta release)
Date: Sat, 10 Mar 2007 16:40:08 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.666

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

According to Eric Blake on 3/10/2007 4:12 PM:
>> while), I still think that if printf.c is going to *assume* unsigned if
>> long long exists, then config.h really ought to make this safe, say by
>> having something like this in config.h.in:
> 
>> #if defined(HAVE_LONG_LONG_INT) && !defined(HAVE_UNSIGNED_LONG_LONG_INT)
>> # undef HAVE_LONG_LONG_INT
>> #endif
> 
> Is it worth patching autoconf's AC_TYPE_LONG_LONG_INT macro to declare
> that there is not a usable 'long long int' type if no corresponding
> unsigned long long type exists?
> 

I tried finding something in POSIX or C99 that said that an implementation
could provide long long without unsigned long long, but did not see
anything obvious (for example, wording on
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html#tag_13_48
implies 64-bit types are optional, but that if int64_t exists, uint64_t
must exist also; and
http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html#tag_13_24
requires LLONG_MIN alongside ULLONG_MAX, both of 64-bit types).
Therefore, we can argue that Tandem is buggy, and that
AC_TYPE_LONG_LONG_INT should fail.  Is this patch okay to apply?  Does it
need a NEWS or documentation entry?

2007-03-10  Eric Blake  <address@hidden>

        * lib/autoconf/types.m4 (AC_TYPE_LONG_LONG_INT): Require unsigned
        long long int, to catch Tandem/NSK bug.

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

iD8DBQFF80HX84KuGfSFAYARAg/GAKCp6mn0dnUJukWETSLHddARoN0sEQCgloiW
lzRFpr/k/ZfUzKLtCETaOn8=
=z3aB
-----END PGP SIGNATURE-----
Index: lib/autoconf/types.m4
===================================================================
RCS file: /sources/autoconf/autoconf/lib/autoconf/types.m4,v
retrieving revision 1.50
diff -u -p -r1.50 types.m4
--- lib/autoconf/types.m4       28 Nov 2006 00:26:45 -0000      1.50
+++ lib/autoconf/types.m4       10 Mar 2007 23:34:12 -0000
@@ -1,7 +1,7 @@
 # This file is part of Autoconf.                       -*- Autoconf -*-
 # Type related macros: existence, sizeof, and structure members.
 #
-# Copyright (C) 2000, 2001, 2002, 2004, 2005, 2006 Free Software
+# Copyright (C) 2000, 2001, 2002, 2004, 2005, 2006, 2007 Free Software
 # Foundation, Inc.
 #
 # This program is free software; you can redistribute it and/or modify
@@ -507,9 +507,13 @@ AC_DEFUN([AC_TYPE_LONG_LONG_INT],
          [ac_cv_type_long_long_int=no],
          [ac_cv_type_long_long_int=yes])],
        [ac_cv_type_long_long_int=no])])
-  if test $ac_cv_type_long_long_int = yes; then
+  dnl This catches a bug in Tandem NonStop Kernel (OSS) cc circa 2004: it
+  dnl provides 'long long int' but not 'unsigned long long int'.
+  AC_REQUIRE([AC_TYPE_UNSIGNED_LONG_LONG_INT])
+  if test $ac_cv_type_long_long_int:$ac_cv_type_unsigned_long_long_int = 
yes:yes; then
     AC_DEFINE([HAVE_LONG_LONG_INT], 1,
-      [Define to 1 if the system has the type `long long int'.])
+      [Define to 1 if the system has the types `long long int' and `unsigned
+long long int'.])
   fi
 ])
 
@@ -944,7 +948,7 @@ AC_DEFUN([AC_STRUCT_TM],
 ],
                                    [struct tm tm;
                                     int *p = &tm.tm_sec;
-                                    return !p;])],
+                                    return !p;])],
                   [ac_cv_struct_tm=time.h],
                   [ac_cv_struct_tm=sys/time.h])])
 if test $ac_cv_struct_tm = sys/time.h; then

reply via email to

[Prev in Thread] Current Thread [Next in Thread]