lkml.org 
[lkml]   [2013]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Suggestion for fixing the variable length array used in the kernel.
On Sat, Mar 09, 2013 at 03:00:54PM -0800, Christopher Li wrote:
> On Sat, Mar 9, 2013 at 2:34 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > The problems is if we go over the 8k stack. So big arrays are bad.
> > Also if the dynamically sized array is inside a loop then normally
> > GCC frees it after each iteration, but on some arches it didn't free
> > it until after the last iteration.
>
> So it seems that you agree those variable array usage should be
> better change to use kmalloc or some thing.
>
> > Btw, I've Smatch has cross function analysis, and I'd like to use
> > it here to figure out if the max size for dynamically sized arrays.
> > I ran into a problem:
> >
> > The code looks like this:
> > char buf[a];
> > The size expression should be an EXPR_SYMBOL, but smatch gets:
> > char buf[*a];
>
> Sparse currently does not deal with the dynamic array size right now.
> It only want to get constant value from the array size.
>
> The part that evaluate the array size is actually correct. Remember
> the EXPR_SYMBOL
> actually contain the *address* of symbol "a". So the proper
> sizeof(buf) is actually
> the content of "*a". That part is fine.

It's evaluating it correctly, but Smatch normally expects
expressions which haven't been evaluated yet.

I can probably hack my own Sparse tree for what I need. It's not a
big deal.

regards,
dan carpenter


\
 
 \ /
  Last update: 2013-03-10 13:21    [W:0.114 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site