RE: [ECOS] Thread error with large buffer

["Trenton D. Adams" <tadams at extremeeng dot com>]

  > >
  > > Yes, I do have ASSERTS/TRACING on, and that's the original reason
I
  > got
  > > the error in the first place.  Anyhow, my original point about
this
  > was
  > > that I don't care at the moment if I put it on the stack or heap.
As
  > > long as my stack is big enough, which it is now, I don't mind for
my
  > > TEST program.
  > >
  > > Isn't my buffer put on the heap if I decide to declare it static?
  > What
  > > about static and global?
  > >
  > >>From what I've always understood, it is on the heap if it's static
  > > because otherwise it would be invalid after the thread was
terminated
  > > since the stack gets deallocated.  static variables are always
valid
  > > from the start of the program until the end.  Except for of course
the
  > > scope of the variable is local to the thread so a pointer to it
would
  > > have to be passed to the main program some way if I wanted to use
it
  > > outside the thread.  No?
  > 
  > Actually, static variables are in a separate "area" - they simply
exist
  > for the lifetime of your program, which in this case is as long as
the
  > target is running that code.  Static variables are put somewhere out
  > there - it matters not where - but most importantly not on your
stack.
  > 
  > The "heap" is actually for objects which have a lifetime less than
  > statics but greater than local [stack] objects.  You create
something
  > on the heap using malloc() and destroy it using free().  If you were
  > writing in C++, you'd create them with the constructor 'new' which
  > in most cases calls malloc() "under the covers"

Is this just the way eCos does it?  Am I correct about other PC based
operating systems?