Re: [PATCH] export -boot parameter as qemu_boot{0,1,2}

[Robert Millan <rmh@aybabtu.com>]

On Mon, Jun 29, 2009 at 06:59:22PM -0400, Pavel Roskin wrote:
> On Mon, 2009-06-29 at 15:49 +0200, Robert Millan wrote:
> 
> > > Use of a nested function seems totally unwarranted.
> > 
> > I did it to make the code more readable.  Declaring functions that will
> > be used locally inside their scope improves code clarity and prevents
> > mistakes (like attempting to run them from somewhere else).
> 
> However, they are not widely used.  In GRUB, nested functions are used
> to allow passing them as callbacks that can access local variables of
> the containing function.
> 
> There is a problem associates with nested functions.  Some versions of
> gcc miscompile them with -mregparm=3.  Arguments other than the first
> one are not passed correctly.  There was a test in configure.ac, but it
> turned out to be wrong, so we are always specifying
> __attribute__((__regparm__(1))) for nested functions taking more than
> one argument on i386 (kernel code only).
> 
> Just look for NESTED_FUNC_ATTR to see what I mean.  We had several bugs
> because NESTED_FUNC_ATTR wasn't used consistently.
> 
> I don't know if NESTED_FUNC_ATTR is needed in your case, or it's only
> needed when the function is passed as an argument.  In any case, I think
> it's an overkill for the problem you are solving.

Isn't this something that should be handled at GCC level?  When you declare a
local variable as "static", GCC knows it should be allocated statically.  Is
there nothing similar for local functions?

I'd rather rewrite the function differently than spreading it in different
parts of the file.  There's no need to make the code harder to figure out
for the sake of this implementation problem.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."