[Top][All Lists]
[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