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: Ralf Wildenhues
Subject: Re: Why AC_C_CHAR_UNSIGNED?
Date: Mon, 4 Aug 2008 07:53:19 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

* Eric Blake wrote on Mon, Aug 04, 2008 at 01:19:32AM CEST:
> According to Bob Friesenhahn on 8/3/2008 5:05 PM:
> | On Sun, 3 Aug 2008, Eric Blake wrote:
> |>
> |> Was there any consensus as to whether obsoleting this macro was
> |> worthwhile?  Remember, making the macro obsolete does not change its
> |
> | Since signed chars have not gone away, I don't think that obsoleting
> | this macro is worthwhile.  There is often an alternative means to find
> | out the same information but since the macro already exists this seems
> | to be a change for the sake of change rather than an improvement.
>
> But I argue that it IS an improvement.

No.  The macro is not broken, don't fix it.  When you receive a bug
report about a system where it is problematic, then fix it.  Until
then, all you're doing is making life harder for users.

Please accept the view that all API changes incur a cost for users.
The benefit must be higher than this cost, in order for a change to
be worthwhile.  IMHO in this case it is not.  It it generally much
more important to not *introduce* bad APIs in the first place, than
to "fix" existing bad APIs.

I reasoned in this thread earlier that Stepan can use a new warning
switch, and I stand by this reasoning.
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/10547/focus=5598>

> We should not be encouraging the
> use of implementation-reserved namespace (__CHAR_UNSIGNED__), when an
> equally portable alternative exists in the user namespace (CHAR_MIN==0).
> In general, any time I see code claiming to be portable but using leading
> __, I have to question what is going on.

Heck, if you need gnulib to defend your reasoning: it has on the order
of 2800 such uses, and claims to be pretty portable.

> (case in point: gnulib still has _loads_ of AC_TRY_COMPILE uses, even
> though it is obsolete and should generally be replaced by AC_COMPILE_IFELSE).

But this is more of a maintainer unwillingness issue.  I've tried to get
patches in before which change this.

Cheers,
Ralf




reply via email to

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