[email protected] (Rusty Russell) wrote on 11.01.03 in <[email protected]>:
> In message <[email protected]> you
> wri te:
> >
> > On Sat, 11 Jan 2003, Rusty Russell wrote:
> > >
> > > Just in case someone names a variable over 2000 chars, and uses it as
> > > an old-style module parameter?
> >
> > No. Just because variable-sized arrays aren't C, and generate crappy code.
> >
> > > for (i = 0; i < num; i++) {
> > > + char sym_name[strlen(obsparm[i].name)
> > > + + sizeof(MODULE_SYMBOL_PREFIX)];
> >
> > It's still there.
>
> OK, *please* explain to me in little words so I can understand.
Do "char sym_name[CONSTANT];". What's so hard to understand about that?
> Variable-sized arrays are C, as of C99. They've been a GNU extension
> forever.
Actually, the gcc thing and the C99 thing are significantly different, and
neither is a sub- or superset of the other. In fact, gcc's C99-conformance
page (http://gcc.gnu.org/c99status.html) still lists VLAs as "broken".
See here for at least some explanation:
http://gcc.gnu.org/ml/gcc/2002-10/msg00470.html
> While gcc 2.95.4 generates fairly horrible code, gcc 3.0 does better
> (the two compilers I have on my laptop).
>
> Both generate correct code.
For the GNU extension, maybe.
MfG Kai
On 13 Jan 2003, Kai Henningsen wrote:
> [email protected] (Rusty Russell) wrote on 11.01.03 in <[email protected]>:
>
> > In message <[email protected]> you
> > wri te:
> > >
> > > On Sat, 11 Jan 2003, Rusty Russell wrote:
> > > >
> > > > Just in case someone names a variable over 2000 chars, and uses it as
> > > > an old-style module parameter?
> > >
> > > No. Just because variable-sized arrays aren't C, and generate crappy code.
> > >
> > > > for (i = 0; i < num; i++) {
> > > > + char sym_name[strlen(obsparm[i].name)
> > > > + + sizeof(MODULE_SYMBOL_PREFIX)];
> > >
> > > It's still there.
> >
> > OK, *please* explain to me in little words so I can understand.
>
> Do "char sym_name[CONSTANT];". What's so hard to understand about that?
>
> > Variable-sized arrays are C, as of C99. They've been a GNU extension
> > forever.
>
> Actually, the gcc thing and the C99 thing are significantly different, and
> neither is a sub- or superset of the other. In fact, gcc's C99-conformance
> page (http://gcc.gnu.org/c99status.html) still lists VLAs as "broken".
>
> See here for at least some explanation:
> http://gcc.gnu.org/ml/gcc/2002-10/msg00470.html
>
> > While gcc 2.95.4 generates fairly horrible code, gcc 3.0 does better
> > (the two compilers I have on my laptop).
> >
> > Both generate correct code.
>
> For the GNU extension, maybe.
>
> MfG Kai
In principle, the idea of variable-length arrays should cause
the compiler to generate very reasonable code because the
length is only a value to subtract from ESP.
void foo(int len)
{
char use[0x100];
char bar[len];
}
In the case of 'use', the compiler subtracts (0x100 * sizeof(char))
from the current stack value and uses that as the location for 'use'.
In the case of 'bar' the compiler subtracts (len * sizeof(char))
from the current stack value and uses that as the location for 'bar'.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Mon, 13 Jan 2003 15:28:45 EST, "Richard B. Johnson" said:
> void foo(int len)
> {
> char use[0x100];
> char bar[len];
> }
>
> In the case of 'use', the compiler subtracts (0x100 * sizeof(char))
> from the current stack value and uses that as the location for 'use'.
> In the case of 'bar' the compiler subtracts (len * sizeof(char))
> from the current stack value and uses that as the location for 'bar'.
One or the other of these is missing a -0x100 for the location...
void foo (int len1, unsigned int len2)
{
char bar[0x100];
char baz[len1];
char quux[len2];
char moby[8];
}
And moby[6] is *where*? ;) Bonus points for getting this right if
compiled with -fvomit-stack-pointer. <evil grin> ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
On Mon, 13 Jan 2003 [email protected] wrote:
> On Mon, 13 Jan 2003 15:28:45 EST, "Richard B. Johnson" said:
>
> > void foo(int len)
> > {
> > char use[0x100];
> > char bar[len];
> > }
> >
> > In the case of 'use', the compiler subtracts (0x100 * sizeof(char))
> > from the current stack value and uses that as the location for 'use'.
> > In the case of 'bar' the compiler subtracts (len * sizeof(char))
> > from the current stack value and uses that as the location for 'bar'.
>
> One or the other of these is missing a -0x100 for the location...
>
> void foo (int len1, unsigned int len2)
> {
> char bar[0x100];
> char baz[len1];
> char quux[len2];
> char moby[8];
> }
>
> And moby[6] is *where*? ;) Bonus points for getting this right if
> compiled with -fvomit-stack-pointer. <evil grin> ;)
> --
Trivial. The constant stuff gets allocated first, then the dynamic.
You can write the code in any order you want, but the code generation
is as though you did:
char bar [0x100];
char moby[8];
Also, vomit-stack-pointer is "f(v)omit-frame-pointer". It works
the same. No problem except when trying to find local variables
in the debugger (known -g implimentation "feature"). The frame
pointer is BP. The stack is never omitted. You can save a few
instructions if you don't use it.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.