From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751576AbbJEOHp (ORCPT ); Mon, 5 Oct 2015 10:07:45 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:38048 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751054AbbJEOHn (ORCPT ); Mon, 5 Oct 2015 10:07:43 -0400 Date: Mon, 5 Oct 2015 16:07:39 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Chris Metcalf , Thomas Gleixner , Peter Zijlstra , Borislav Petkov , open list , "H. Peter Anvin" Subject: Re: [PATCH] string: Improve the generic strlcpy() implementation Message-ID: <20151005140739.GA7478@gmail.com> References: <55F1DD53.1070102@ezchip.com> <20151005112700.GA1096@gmail.com> <20151005115355.GA27073@gmail.com> <20151005131524.GA807@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Linus Torvalds wrote: > On Oct 5, 2015 14:15, "Ingo Molnar" wrote: > > > > Hm, so GCC (v4.9.2) will only warn about this bug if -Wtype-limits is enabled > > explicitly: > > Some of the warnings are really nasty, and cause people to write worse code. > > For example, this is inherently good code: > > if (x < 0 || x > MAXLEN) > return -EINVAL; > > and a compiler that warns about that is pure and utter crap. Obviously. Agreed? > > Now, imagine that "x" here is some random type. Maybe it's s "char" and you > don't even know the sign. Maybe it's "loff_t". Maybe it's "size_t", or whatever. > > Note how that test is correct *regardless* of the sign of the type. A compiler > that warns about the "x < 0" part just because x happens to be unsigned is a bad > bad compiler, and makes people remove that check, even though it's good for > readability, and good for robustness wrt changing the type. Yeah, that's true. > We really do have types where sightedness depends on architecture or > possibly configuration options. "char" is the obvious example, but the type > limit can matter too: on some architectures you might have a type that is > 16 bits, on another it might be 32 bits. Do you really think that > > if (x > 65535) > return -E2BIG; > > should have some #ifdef __xyz__ around it just because the compiler warns > if the type happens to be 16 bits wide? > > So type limit warnings break not things than they fix. Yeah, too bad. > These things come up in macros too (think range checking etc). > > In other words, that warning really isn't good if it's done mindlessly. And I've > never seen a compiler that did it sanely and trying to take context into > account. > > So no. Don't enable that broken warning. We have had it on, and it caused people > to send in patches for warnings that made the code actively worse. Okay. Please disregard my other mail. Thanks, Ingo