This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Thread error with large buffer


  > 
  > But you put it on the stack - that's the way you declared it to "C".
  > Putting
  > it on the heap can only be done explicitly, via malloc().
  > 
  > The point is, though, that we do need to be mindful of these things.
  > Turning
  > on stack checking code with asserts, as Dan recommended, is the way
to
  > find
  > these little nits - eCos is an embedded system and for the most
part,
  > you
  > have to protect yourself because it can't protect for you.
  > 
  > Note: on a system with full protection, such as Linux, you would
have
  > gotten
  > an immediate failure when you tried to overextend your stack.  We
simply
  > can't
  > provide that kind of protection on eCos (at least in the general
case).
  > Thus
  > the ability to validate the stack, etc.

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]