From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751792AbcCJOAQ (ORCPT ); Thu, 10 Mar 2016 09:00:16 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:34634 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751710AbcCJOAL (ORCPT ); Thu, 10 Mar 2016 09:00:11 -0500 Date: Thu, 10 Mar 2016 13:59:43 +0000 From: One Thousand Gnomes To: Andrew Morton Cc: Rasmus Villemoes , Kees Cook , linux-kernel@vger.kernel.org Subject: Re: [RFC 0/7] eliminate snprintf with overlapping src and dst Message-ID: <20160310135943.762b888d@lxorguk.ukuu.org.uk> In-Reply-To: <20160309124940.7d870c59a7a7117c6c6d7937@linux-foundation.org> References: <1457469654-17059-1-git-send-email-linux@rasmusvillemoes.dk> <20160309124940.7d870c59a7a7117c6c6d7937@linux-foundation.org> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 9 Mar 2016 12:49:40 -0800 Andrew Morton wrote: > On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes wrote: > > > Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer > > currently works, but it is somewhat fragile, and any other overlap > > between source and destination buffers would be a definite bug. This > > is an attempt at eliminating the relatively few occurences of this > > pattern in the kernel. > > I dunno, > > snprintf(analog->name, sizeof(analog->name), "Analog %d-axis %d-button", > > is pretty damn convenient. Can we instead state that "sprintf shall > support this"? Maybe add a little __init testcase to vsprintf.c to > check that it continues to work OK. We can just document that it does for the specific case. Or if anyone is worried it can easily be wrapped as sncatf() in case the property changes 8) If you go the seq_* way then IMHO a debug enabled check that no %s argument matches the passed source string in the kernel snprintf would be a good addition to go with it, so that the behaviour cannot be re-introduced. Given it works and it's useful and we have no reason to make it stop working I don't see why it shouldn't just be documented as a property of the kernel snprintf. The kernel makes plenty of other assumptions that are not strictly C standards compliant 8) Alan