[MPlayer-dev-eng] [PATCH] Add a function for parse and queue multiple cmds seperated by line-break

Ulion ulion2002 at gmail.com
Tue Dec 11 09:04:15 CET 2007


2007/12/10, Ulion <ulion2002 at gmail.com>:
> 2007/12/9, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > Hello,
> > On Sun, Dec 09, 2007 at 09:37:18PM +0800, Ulion wrote:
> > > 2007/12/9, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > [...]
> > > > > +    while (*str == '\n')
> > > > > +        ++str;
> > > > > +    while (*str) {
> > > > > +        size_t len = strcspn(str, "\n");
> > > > > +        char cmdbuf[len+1];
> > > >
> > > > Hmm... I think creating arbitrary-size arrays on the stack is a really
> > > > bad idea, what does everyone else think?
> > >
> > > I have no idea how the compiler handle such declaration. Indeed I
> > > never known an array can have a dynamic size declaration before I
> > > touch mplayer's code. Anyone can explain that to me?
> >
> > Well, it's not difficult, the size of the array is subtracted from the
> > current stack pointer and then you have a new stack pointer that points
> > to the start of your array.
> > The problem with this here is, that string in theory could be e.g. 500
> > MB large. As I learned it, the area reserved for your stack is usually
> > at most 20 MB large though, so like that you would be writing outside
> > the stack, possibly into something that is already used otherwise,
> > e.g. another thread's stack or the heap (malloc'd stuff), with
> > all the problems that entails...
> > If your data is at most e.g. 1 MB that is not a problem usually, because
> > your OS should set up "guard" pages below your stack, so as long as
> > you only allocate small things and access them as well you can be sure
> > your program will crash before it reaches beyond the stack and somewhere
> > it shouldn't be.
> > With 64 bit systems the issue is smaller, since the guard areas can be
> > made large enough that you can't break out at least with and "int"
> > index, at least for single-threaded applications.
>
> OK, I will use this malloc version for commit tomorrow.

Commited.

-- 
Ulion



More information about the MPlayer-dev-eng mailing list