autoconf-patches
[Top][All Lists]
Advanced

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

Re: Why AC_C_CHAR_UNSIGNED?


From: Eric Blake
Subject: Re: Why AC_C_CHAR_UNSIGNED?
Date: Sun, 03 Aug 2008 16:39:28 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666

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

Just now reading this thread from a month ago:

According to Stepan Kasal on 6/24/2008 9:31 AM:
| Hello,
|
| On Mon, Jun 23, 2008 at 04:05:21PM -0500, Bob Friesenhahn wrote:
|> My own software does not currently depend on limits.h but tests I did
|> separately on many types of systems (including several 12 year old ones)
|> with a program which specifically exercises limits.h (including 'char')
|> did not encounter any problems.
|
| thank you for your information.  On that ground, I have prepared the
| following patch.  Ok to commit?

Subject: [PATCH] Make AC_C_CHAR_UNSIGNED obsolete.

| * lib/autoconf/c.m4 (AC_C_CHAR_UNSIGNED): Warn that it is obsolete;
| reported by Hallvard B Furuseth.
| * doc/autoconf.texi (C Compiler): Move AC_C_CHAR_UNSIGNED...
| (Obsolete Macros): ...here, and mention why.
| * NEWS: Mention.

Was there any consensus as to whether obsoleting this macro was
worthwhile?  Remember, making the macro obsolete does not change its
functionality (ie. older packages that used the macro and depended on the
definition of __CHAR_UNSIGNED__ rather than CHAR_MIN==0 will still
compile), other than the addition of a warning under autoconf -Wall.  If
someone is intentionally changing configure.ac in order to silence -Wall
warnings, then they should also be smart enough to modify whatever other
code is necessary to rely on CHAR_MIN==0.  And I personally don't like the
idea of autoconf defining macros in the namespace reserved to
implementations, if we can avoid it.  So as an autoconf maintainer, I'm in
favor of the obsoletion.  I'll wait a couple days for any final comments
(or even better, a rebased patch against current git sources), then commit
something close to Stepan's proposal if there are no strong objections in
that time.

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

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

iEYEARECAAYFAkiWM6AACgkQ84KuGfSFAYC0tQCdEWICUu4Wn5Q/66bUcrkKQy+q
IlYAoL35bqaad4iCeuuq2wiUV2gSC+zc
=SkcG
-----END PGP SIGNATURE-----




reply via email to

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