On Wed, Sep 30 2015, Mark Brown <[email protected]> wrote: > On Wed, Sep 30, 2015 at 09:27:38AM +0200, Rasmus Villemoes wrote: > >> I agree, but only on the word 'great'. There is value in removing such >> bogosities (or rather, their presence provides negative value). It makes >> the code harder to read ("why is this instance checked, but not any of >> the other snprintfs?"); people may think that it's trying to check for >> truncation, but it does no such thing; and it contributes a few >> worthless bytes to .text (and the source). > > The solution to partial error checking isn't always to remove the error > checking!
Since this particular piece of code is not, in fact, doing any kind of error checking, I fail to see how that argument is relevant. Or, more constructively: Would you please explain exactly what error checking you think this should/could be doing? Truncation? Invalid format string? Cosmic-ray-detected? >> If you're worried about map->dev->driver->name actually ever being > 2G, >> returning some almost totally random negative number isn't really >> helpful (the function is supposed to return a -errno). And what makes >> you think that in some hypothetical universe where the kernel's snprintf >> explicit returns a negative value that it wouldn't just return -1 (aka >> -EPERM)? > > This is going back to the discussion about having to learn the specific > snprinf() implementation one is dealing with. You better know what values it might return under which circumstances if you're going to forward those as error codes to your caller. Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
