From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9992 invoked by alias); 3 Mar 2011 10:20:37 -0000 Received: (qmail 9982 invoked by uid 22791); 3 Mar 2011 10:20:36 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_CP,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Mar 2011 10:20:31 +0000 Received: (qmail 1322 invoked from network); 3 Mar 2011 10:20:29 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Mar 2011 10:20:29 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [commit] printcmd.c, print_scalar_formatted, use strncpy. Date: Thu, 03 Mar 2011 10:20:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.0; x86_64; ; ) Cc: Michael Snyder References: <4D6ECC07.40905@vmware.com> <201103022341.55237.pedro@codesourcery.com> <4D6ED920.6090206@vmware.com> In-Reply-To: <4D6ED920.6090206@vmware.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103031020.35944.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00164.txt.bz2 On Wednesday 02 March 2011 23:56:16, Michael Snyder wrote: > Pedro Alves wrote: > > On Wednesday 02 March 2011 23:00:23, Michael Snyder wrote: > >> 2011-03-02 Michael Snyder > >> > >> * printcmd.c (print_scalar_formatted): Use strncpy for safety. > >> - strcpy (buf, cp); > >> + strncpy (buf, cp, sizeof (bits)); > >> fputs_filtered (buf, stream); > > We've been through this recently... This is not safe. > > > > I'm slow today -- how is it not safe? > > (note that sizeof (bits) is smaller than sizeof (buff)). In that case the change is useless. In the case you're thinking strncpy is safer (to prevent overflow), it does _not_ add the terminating null byte to the destination. See its linux man page, please. If the change hadn't been useless for the reason above, you'd've shifted the problem elsewhere, not made things safer, because if the safety net had been hit, the fputs_filtered in the next line would do undefined things, like for example crash, when trying to print a not null-terminated BUF. strncpy was _not_ designed as a safe version of strcpy. It was designed to be used on fixed length fields in things like databases, where if you don't null terminate the destination, it's okay, because _users_ of the data in the buffer know how to handle that. Here : "4.11.2.4 The strncpy function strncpy was initially introduced into the C library to deal with fixed-length name fields in structures such as directory entries. Such fields are not used in the same way as strings: the trailing null is unnecessary for a maximum-length field, and setting trailing bytes for shorter names to null assures efficient field-wise comparisons. strncpy is not by origin a ``bounded strcpy,'' and the Committee has preferred to recognize existing practice rather than alter the function to better suit it to such use." So, to recap, simply s/strcpy/strncpy/ is not any safer. -- Pedro Alves