* 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
