From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A73F2C3A5A5 for ; Mon, 26 Aug 2019 08:58:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 85F092087E for ; Mon, 26 Aug 2019 08:58:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730478AbfHZI6w (ORCPT ); Mon, 26 Aug 2019 04:58:52 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:46311 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729854AbfHZI6v (ORCPT ); Mon, 26 Aug 2019 04:58:51 -0400 Received: by mail-oi1-f194.google.com with SMTP id t24so11504471oij.13; Mon, 26 Aug 2019 01:58:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tnEOaWMh9o7a4lsL8t46ApShoBTiXhp9jJWi58Cb5Gc=; b=gNTC26TCRuhPCnmLwV5ci68NVeucexpxmpB1zZ5+bnany2+xp/mtE3YzqxreRpNFxK DdFU21+dZU3gMwdgfNjFzatQOh3il9bMnPF6ZGFXOKfBjL1DdOxA7SUnIFVcFIg28kNC 9FzCvHJdW+D6G25inX+wGKdhB6VHtn1O9LCIB06t9B5nymrYZIIgjflUgvzYLASNoo3S RjKUqqWucD0lnA1490FxRzyERKwRG8R0YNe8cE/6zGZ8CdzZErgAtBWBQ4SS1YmRIL4b OfqtA1leb5iWDXKj2g3BExtshV9AO4ObjXVurg05FiqeJsM8vcCkYBualjbq24tZVV3Q PSoA== X-Gm-Message-State: APjAAAVDJsd/v1pjsT7NGK35NBnsDdKDQ7nj2NdUREG3SjUT8HhTPGXe IeiVNelAiOktV4RQIehY7WXROxbKveTBNMGOY2A= X-Google-Smtp-Source: APXvYqxXAEmTrR0e9s0qceFFoDeOwnHS/Xoq0e/yv+MEHb3J0+ID75RlA2eDMhAg81C5BpolzjElQX/42D45ESS6+Fk= X-Received: by 2002:a54:478d:: with SMTP id o13mr11607090oic.54.1566809930697; Mon, 26 Aug 2019 01:58:50 -0700 (PDT) MIME-Version: 1.0 References: <9c7a79b4d21aea52464d00c8fa4e4b92638560b6.camel@perches.com> <6a5f470c1375289908c37632572c4aa60d6486fa.camel@perches.com> <4398924f28a58fca296d101dae11e7accce80656.camel@perches.com> <20190820092451.791c85e5@canb.auug.org.au> <14723fccc2c3362cc045df17fc8554f37c8a8529.camel@perches.com> <9d12995c5e7e41fc5d8ba202f76a2cf854183245.camel@perches.com> In-Reply-To: From: Geert Uytterhoeven Date: Mon, 26 Aug 2019 10:58:39 +0200 Message-ID: Subject: Re: rfc: treewide scripted patch mechanism? (was: Re: [PATCH] Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang)QUILT To: Linus Torvalds Cc: Joe Perches , Stephen Rothwell , Julia Lawall , "Gustavo A. R. Silva" , LKML , clang-built-linux@googlegroups.com, Linux Next Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, On Wed, Aug 21, 2019 at 2:41 AM Linus Torvalds wrote: > On Tue, Aug 20, 2019 at 4:37 PM Joe Perches wrote: > > > So I'm putting my foot down on yet another broken string copy > > > interface from people who do not understand this fundamental issue. > > > > I think you are mistaken about the stracpy limits as > > the only limit is not the source size but the dest. > > > > Why should the source be size limited? > > You just proved my point. You don't understand that sources can also > be limited, and the limit on a source can be *smaller* than the limit > of a destination. > > Did we learn *NOTHING* from the complete and utter disaster that was strlcpy()? > > Do you not understand why strlcpy() was unacceptably bad, and why the > people who converted strncpy() to it introduced real bugs? > > The fact is, it's not just the destination that has a size limit. The > source often has one too. > > And no, the source is not always guaranteed to be NUL-terminated, nor > is the source buffer guaranteed to be larger than the destination > buffer. > > Now, if you *know* that the source is smaller than the destination > size, you can do: > > len = strnlen(src, srclen); > memcpy(dst, len); > dst[len] = 0; > > and that's not wrong, but that works only when > > (a) you actually do the above > > (b) you have no data races on src (or you at least only require that > 'dst' is NUL-terminated, not that 'len' is necessarily the correct > length of the result > > (c) you actually know as the programmer that yes, the source is > definitely smaller than the destination. > > and honestly, people don't get _any_ of that right. (d) you know the untouched trailing end of dst[] does not leak data. Anything else we're missing? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds