Make `obsolete params' work correctly if MODULE_SYMBOL_PRE
A message that is not in the archive (sent off-list or not yet received): [email protected]
[email protected] (Rusty Russell) wrote on 11.01.03 in <[email protected]>:
Quoted 10 lines
In message <[email protected]> you wri te:
Quoted 8 lines · Rusty Russell
Quoted 3 lines
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.
Quoted 7 lines
Quoted 5 lines
Review
Quoted 3 lines
(quoted diff) +2
-0for (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?
Quoted 2 lines
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
Quoted 4 lines
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
Quoted 32 lines · Kai Henningsen
[email protected] (Rusty Russell) wrote on 11.01.03 in <[email protected]>:
Quoted 10 lines
In message <[email protected]> you wri te:
Quoted 8 lines · Rusty Russell
Quoted 3 lines
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.
Quoted 7 lines
Quoted 5 lines
Review
Quoted 3 lines
(quoted diff) +2
-0for (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?
Quoted 2 lines
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
Quoted 8 lines
Quoted 4 lines
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.
Quoted 10 lines · Richard B. Johnson
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> ;)
Signature · 3 lines
Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Quoted 23 lines · On Mon, 13 Jan 2003 [email protected] wrote:
Quoted 10 lines · Richard B. Johnson
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];
}
Quoted 3 lines
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.