On 6 Sep 2011, Junio C. Hamano spake thusly: > Nix <nix@xxxxxxxxxxxxx> 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) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html