From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BcALG-0001rl-Dn for qemu-devel@nongnu.org; Sun, 20 Jun 2004 17:59:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BcALD-0001pz-BM for qemu-devel@nongnu.org; Sun, 20 Jun 2004 17:59:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BcALD-0001pw-A2 for qemu-devel@nongnu.org; Sun, 20 Jun 2004 17:59:07 -0400 Received: from [206.72.67.39] (helo=claudius.sentinelchicken.org) by monty-python.gnu.org with smtp (Exim 4.34) id 1BcAJs-0001ad-Ms for qemu-devel@nongnu.org; Sun, 20 Jun 2004 17:57:45 -0400 Date: Sun, 20 Jun 2004 14:57:43 -0700 From: Tim Subject: Re: [Qemu-devel] Re: Re: [PATCH] security_20040618 Message-ID: <20040620215743.GB1927@sentinelchicken.org> References: <20040620192652.GA1927@sentinelchicken.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > Based on comments received thus far, including yours, I am reviewing > > that section of code (as I mentioned above), and will be releasing a new > > revision of the patch in a day or two. I admit, I am not a perfect > > programmer. I am merely trying to help out by fixing the tiny problems > > that are often missed by programmers that have more important things to > > worry about. I appreciate it when people show me where I am wrong, but > > could you please keep your criticism a bit more constructive? > > Sorry if I sounded a bit harsh, I'm sure every contribution is appreciated, > and your submitting patches is more helpful than my criticizing them... That's ok, I was just taken aback a bit. > I merely wanted to emphasize how broken strncpy is and how much more useful > pstrcpy is. > > My suggestion on qemu_strdup is imho constructive :-) and about the only > reason this is not completely off topic ;-) > > But as far as strnpy is concerned, I *want* to be destructive : this C > library function is a mess, it doesn't do what most C programmers > believe. It causes bugs, or blatant inefficiencies due to the inept null > padding on large buffers. > It is so unlikely that the precise behaviour of that horrible thing be what > is needed in any C program... > There are quite a few problems around uses of this function even in gnu > software or the linux kernel. Yes, since Fabrice pointed out the differences between my version of pstrcpy() and his, I have come to appreciate pstrcpy()'s correctness and speed. I see what you mean by the problems with strncpy(), and I'll make an effort to eliminate it with the same prejudice I have tried to eliminate most strcpy() and sprintf() calls. > There are other candidates for libc functions every programmer should reject > disgruntedly : sprintf, gets, strtok, mktemp, tmpnam, > tempnam... or any of the C library functions duly tagged in the man pages as > never to be used > Similarly, extreme care is needed in do/while loops... Agreed. In this day and age, there's really no excuse to use unsafe functions such as these. That's why I attempt to eliminate them with my patch even though there may be no immediately obvious overflow issue. Thanks for the additional comments & information. cheers, tim