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

[David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>]

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