From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9686 invoked by alias); 2 May 2006 14:58:11 -0000 Received: (qmail 9674 invoked by uid 22791); 2 May 2006 14:58:09 -0000 X-Spam-Check-By: sourceware.org Received: from smtp102.sbc.mail.mud.yahoo.com (HELO smtp102.sbc.mail.mud.yahoo.com) (68.142.198.201) by sourceware.org (qpsmtpd/0.31) with SMTP; Tue, 02 May 2006 14:58:05 +0000 Received: (qmail 54417 invoked from network); 2 May 2006 14:58:04 -0000 Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@75.0.171.244 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 2 May 2006 14:58:03 -0000 Received: by lucon.org (Postfix, from userid 1000) id 5F83364034; Tue, 2 May 2006 07:58:00 -0700 (PDT) Date: Tue, 02 May 2006 14:58:00 -0000 From: "H. J. Lu" To: Jan Beulich Cc: Nick Clifton , binutils@sources.redhat.com Subject: Re: PATCH: Fix buffer overflow in gas Message-ID: <20060502145800.GA10963@lucon.org> References: <20060501184006.GA2583@lucon.org> <44572AAF.4080203@redhat.com> <20060502133130.GB10201@lucon.org> <20060502142031.GA10660@lucon.org> <44578A83.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44578A83.76E4.0078.0@novell.com> User-Agent: Mutt/1.4.2.1i Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00050.txt.bz2 On Tue, May 02, 2006 at 04:36:19PM +0200, Jan Beulich wrote: > >+static char output_invalid_buf[sizeof (unsigned char) * 2 + 6]; > > I'm sorry to say that this, but regardless of actual width of 'char' or 'unsigned char' the above declaration still > always produces an 8-unit array. What you mean is making room for as many hex digits as an 'unsigned char' can be > converted to. Without knowing CHAR_BIT (or equivalent) I cannot see how you would be able to derive that. Unfortunately, > previous work on binutils has shown that one apparently shouldn't make assumptions about the availability of limits.h > (despite this having been a standard header for at least 15 years), and hence CHAR_BIT is not generally usable here. > Where needed, I (and apparently others) generally made the assumption that if limits.h isn't available, then the machine > is supposed to be a 8-bit-bytes one (and bad luck to those perhaps hypothetical machines that aren't and that don't > provide the header). I don't want to get too complicated here. We won't have buffer overflow anymore no matter what CHAR_BIT is. Feel free to improve it. H.J.