From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752543AbbLEUmn (ORCPT ); Sat, 5 Dec 2015 15:42:43 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:22435 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbbLEUmm (ORCPT ); Sat, 5 Dec 2015 15:42:42 -0500 X-IronPort-AV: E=Sophos;i="5.20,386,1444687200"; d="scan'208";a="190586974" Date: Sat, 5 Dec 2015 21:42:40 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Rasmus Villemoes cc: linux-kernel@vger.kernel.org, Kees Cook , Andrew Morton Subject: Re: snprintf, overlapping destination and source In-Reply-To: <87d1ukr5pf.fsf@rasmusvillemoes.dk> Message-ID: References: <87d1ukr5pf.fsf@rasmusvillemoes.dk> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 5 Dec 2015, Rasmus Villemoes wrote: > I did a search for code doing > > s[n]printf(buf, "...", ..., buf, ...) > > and found a few instances. They all do it with the format string > beginning with "%s" and buf being passed as the corresponding parameter > (obviously to append to the existing string). That works (AFAICT), both > with the current printf implementation and with the string() > modification which is now in -mm. It would obviously go horribly wrong > if anything, even non-specifiers, precede the "%s" in the format > string. > > The question is, do we want to officially support this particular case of > overlapping src and dst? Or should we close our eyes and hope it will > continue to work [1] and that it won't cause a caffeine-deprived hacker > to accidentally think one could also prepend to a buffer by doing > sprintf(buf, "...%s", ..., buf)? I'm actually surprised gcc doesn't warn > about this. > > [1] Not that I can immediately think of a sane way to implement snprintf > where it won't work, but you never know... > > My coccinelle-fu isn't sufficient to find cases where one of the buf > instances is a more complicated expressions involving buf as a > subexpression, as in > > s[n]printf(buf, "...", ..., buf + 4, ...) > > or > > s[n]printf(&buf[len], "...", ..., buf, ...) > > which would presumably always be wrong. Julia? If you just want an argument expression that contains buf somewhere, you can write <+...buf...+>. julia