:>     I'm sorry, but when you write code for a safety related system you
:>     do not dynamically allocate memory at all.  It's all essentially static.
:>     There is no issue with the memory resource.  Besides, none of the BSD's are
:>     certified for any of that stuff that I know of.
:
:Sometimes it's not feasible to statically allocate memory.  You
:dynamically allocate all the memory you need at program initialization 
:(and no, we don't want to manage a pool of memory ourselves - that's
:what the OS is for).  
:...
:Note that languages such as Ada raise exceptions when memory allocation
:fails.  The underlying run-time relies on malloc returning null in
:order to raise an exception.  Normally, programs written in Ada

    Simply set a resource limit. 

    You are making the classic mistake of assuming that a fail-safe in the
    O.S. must be integrated all the way down into the user level when, 
    in fact, it is simply a matter of setting a resource limit.

    When you are running an embedded system and have full control over the
    software being run, setting resource limits will do what you want.  By
    doing so you are effectively managing the software modules on a 
    module-by-module basis and not allowing one module to indirectly effect
    another.  This is what you want to do in an embedded system:  You do
    not want to create a situation where a failure in one module cascades
    into others.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:take great care to gracefully handle these exceptions.  All the C
:programs that we've ever written also take great care in handling
:NULL returns from malloc.
:
:I have no problem with overcommit, but I can see the need that
:some folks have for turning it off.  If you don't want to write
:the code to allow this, that's fine - you don't want/need it,
:so why should you?  But if other folks see a need for it, let
:_them_ write the hooks for it :-)
:
:Dan Eischen
:eischen@vigrid.com
: