From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hopwood Subject: Re: [PATCH] Off-by-one in cpu_gdt_init Date: Tue, 07 Jun 2005 23:03:50 +0100 Message-ID: <42A619C6.8000700@blueyonder.co.uk> References: <42A47657.7020107@blueyonder.co.uk> <1118105301.7703.16.camel@localhost.localdomain> Reply-To: david.nospam.hopwood@blueyonder.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1118105301.7703.16.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Rusty Russell wrote: > On Mon, 2005-06-06 at 17:14 +0100, David Hopwood wrote: >>George Washington Dunlap III wrote: >> >>> void __init cpu_gdt_init(struct Xgt_desc_struct *gdt_descr) >>> { >>>- unsigned long frames[gdt_descr->size >> PAGE_SHIFT]; >>>+ unsigned long frames[(gdt_descr->size >> PAGE_SHIFT)+1]; >> >>Variable-length arrays? Never use variable-length arrays in code that needs >>to be robust: you can't guarantee that the stack won't overflow. If it does, >>there is no way to detect that situtation (unlike malloc et al where you can >>check for NULL), you just get undefined behaviour. > > Yes, and no. > > It's pretty normal not to check malloc returns in init code: if it fails > what could be more informative than an OOPS? If a NULL return is in fact guaranteed to cause an oops (which depends on how and when the pointer is used), possibly. But even then I prefer an error message that explicitly says what has failed. > You're in deep trouble already. Well, I'm used to embedded systems without memory protection where a NULL pointer dereference or stack overflow generally does not cause an oops. But I think it's bad practice to rely on oopses rather than explicit checking, even on systems that guarantee an oops will occur. -- David Hopwood