From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 16:32:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D0D10656B5; Wed, 8 Sep 2010 16:32:14 +0000 (UTC) (envelope-from rink@gloom.codethulu.net) Received: from mx1.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.freebsd.org (Postfix) with ESMTP id EACF98FC08; Wed, 8 Sep 2010 16:32:13 +0000 (UTC) Received: from anathema.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.codethulu.net (Postfix) with ESMTP id 99C1F3782C42; Wed, 8 Sep 2010 18:15:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at codethulu.net Received: from mx1.codethulu.net ([77.243.236.173]) by anathema.codethulu.net (anathema.codethulu.net [77.243.236.173]) (amavisd-new, port 10024) with ESMTP id usAHiAeEzax6; Wed, 8 Sep 2010 18:15:31 +0200 (CEST) Received: from gloom.codethulu.net (mail.codethulu.net [77.243.236.173]) by mx1.codethulu.net (Postfix) with ESMTP id 77E9A378258D; Wed, 8 Sep 2010 18:15:31 +0200 (CEST) Received: by gloom.codethulu.net (Postfix, from userid 1000) id 6AD5A6D455; Wed, 8 Sep 2010 18:15:31 +0200 (CEST) Date: Wed, 8 Sep 2010 18:15:31 +0200 From: Rink Springer To: mdf@FreeBSD.org Message-ID: <20100908161531.GJ37467@rink.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: deprecating sprintf(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 16:32:14 -0000 Hi, On Wed, Sep 08, 2010 at 08:51:57AM -0700, mdf@FreeBSD.org wrote: > It seems like a large project, but OTOH sprintf(9) is mighty unsafe in > the kernel. It's disapproved of for user-space as being unsafe for > security reasons as well, but the potential downsides aren't the same, > and we'll never clean up ports anyways. :-) Deprecating it may be usable, yet I don't believe we can easily enforce such a policy [1]. Have you looked at how many (potentially) unsecure uses there are in the kernel, to give an idea how useful such an effort would be? [1] Unless we'd go through things like Visual Studio's #define strcpy __strcpy_unsafe_use_string_cb_copy stuff... Regards, -- Rink P.W. Springer - http://rink.nu "The power of accurate observation is commonly called cynicism by those who have not got it." - George Bernard Shaw