On 5 Sep 2011, Sverre Rabbelier said: > Heya, > > On Mon, Sep 5, 2011 at 13:45, Nix <nix@xxxxxxxxxxxxx> wrote: >> 32-bit platforms with no type larger than 'long' cannot detect this >> case and will continue to silently misbehave, but the misbehaviour >> will be somewhat different and more useful, since bigFileThreshold was >> also being mistakenly treated as a signed value when it should have >> been unsigned. > > Is it not possible to detect that the target value won't fit in the > max size of an int when parsing the config value? Well, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we have long long and sizeof(long long)>sizeof(int), then we can always detect overflows when saving into the appropriate type: but if we don't have long long, or if we have neither strto(u)ll() nor strto[ui]max(), we could only detect overflow by looking at the raw text string and checking it by hand to see if it would fit. I judged this pointless extra complexity for a very rare edge case (machines with neither strot(u)ll() nor strto[ui]max() are generally quite old and people aren't going to be specifying sizes in gigabytes on such machines anyway.) -- 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