Re: [PATCH 1/2] Add strtoimax() compatibility function.
- From
Nix <nix@esperi.org.uk>
- Date
- Sep 6, 2011, 09:14 UTC
- 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:
Show 12 quoted lines
> 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.
Show 5 quoted lines
> 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)