WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Off-by-one in cpu_gdt_init

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 <david.nospam.hopwood@xxxxxxxxxxxxxxxx>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>