From: Nix <nix@esperi.org.uk>
Date: Tue, 06 Sep 2011 09:14:16 GMT
Subject: Re: [PATCH 1/2] Add strtoimax() compatibility function.
Message-ID: <87pqjejamv.fsf@spindle.srvr.nix>
In-Reply-To: <7v62l6b3bt.fsf@alter.siamese.dyndns.org>

On 6 Sep 2011, Junio C. Hamano spake thusly:

> Nix <nix@esperi.org.uk> writes:
>
>> Since systems that omit strtoumax() will likely omit strtomax() too,
>> and likewise for strtoull() and strtoll(), we also adjust the
>> compatibility #defines from NO_STRTOUMAX to NO_STRTOMAX and from
>> NO_STRTOULL to NO_STRTOLL, and have them cover both the signed and
>> unsigned functions.
>
> What would happen to people who know their systems lack strtoumax and have
> happily using NO_STRTOUMAX in their config.mak already? Do their build
> suddenly start breaking after this patch is applied and they all have to
> adjust to the new name?

Uh. Yeah. Oops.

> Even though "no strtoumax() likely means no strtoimax()" may be a good
> heuristics, I am not sure what we would gain by renaming these Makefile
> variables. Can't you get the same effect by making existing NO_STRTOUMAX
> imply not having strtoimax(), and if you did so, wouldn't it be much less
> likely that you would break existing people's build?

Yes, but I thought that might be too confusing (and having four
variables for this one case seemed ridiculous). I'm happy to rename it
back.

-- 
NULL && (void)