From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933084AbbI3Rwb (ORCPT ); Wed, 30 Sep 2015 13:52:31 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:36131 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932255AbbI3Rw3 (ORCPT ); Wed, 30 Sep 2015 13:52:29 -0400 From: Rasmus Villemoes To: Mark Brown Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] regmap: debugfs: remove bogus check Organization: D03 References: <1443479342-31621-1-git-send-email-linux@rasmusvillemoes.dk> <20150929181455.GB30445@sirena.org.uk> <87pp10l639.fsf@rasmusvillemoes.dk> <20150930172045.GE15635@sirena.org.uk> X-Hashcash: 1:20:150930:broonie@kernel.org::OLSvd+QQTKNbKzpY:00000000000000000000000000000000000000000001ONl X-Hashcash: 1:20:150930:gregkh@linuxfoundation.org::daqMKr3MspsMyvdZ:0000000000000000000000000000000000011U+ X-Hashcash: 1:20:150930:linux-kernel@vger.kernel.org::nx4F3kCnhzuhXrFy:0000000000000000000000000000000008oKx Date: Wed, 30 Sep 2015 19:52:26 +0200 In-Reply-To: <20150930172045.GE15635@sirena.org.uk> (Mark Brown's message of "Wed, 30 Sep 2015 18:20:45 +0100") Message-ID: <87d1wzg5gl.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30 2015, Mark Brown 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