Memory Allocation : Static or Dynamic?

Discussion in 'C Programming' started by swornavidhya.mahadevan@gmail.com, May 8, 2008.

  1. Guest

    Which allocation (Static / Dynamic) is suitable for the situation when
    we are trying to allocate for a overloaded memory when the memory is
    full and no space to allocate.
    What will happen if both the allocation is impossible.

    Sworna vidhya
    , May 8, 2008
    #1
    1. Advertising

  2. On 8 May 2008 at 16:58, wrote:
    > Which allocation (Static / Dynamic) is suitable for the situation when
    > we are trying to allocate for a overloaded memory when the memory is
    > full and no space to allocate.
    > What will happen if both the allocation is impossible.


    Definitely use dynamic allocation if there's a serious risk of running
    out of memory (and as a general principle, don't allocate large arrays
    on the stack). If malloc() fails, you can detect this (it will return a
    null pointer) and attempt to recover or exit cleanly. If you run out of
    static memory for your automatic variables, the most likely outcome is
    that the heap will become corrupted without warning. If you're lucky,
    your program will quickly segfault; if your unlucky, you could go on for
    hours processing corrupted data.

    What's going on is that in your process's virtual address space, memory
    is arranged like this:

    -----------------------
    | |
    | STACK |
    | (grows downwards) |
    | |
    -----------------------
    | |
    | FREE MEMORY |
    | (available for the |
    | stack or heap) |
    | |
    -----------------------
    | |
    | HEAP |
    | (grows upwards) |
    | |
    -----------------------

    So if you run out of free memory and overflow the stack, you can see
    that bad things will happen.
    Antoninus Twink, May 8, 2008
    #2
    1. Advertising

  3. In article <>,
    <> wrote:

    >Which allocation (Static / Dynamic) is suitable for the situation when
    >we are trying to allocate for a overloaded memory when the memory is
    >full and no space to allocate.
    >What will happen if both the allocation is impossible.


    Sounds like a homework question to me...

    But anyhow: The failure of dynamic allocation has well-defined
    results: all of the dynamic allocation functions have methods
    of indicating that they were unable to allocate more memory. This
    allows you to cleanly detect and take action when memory is full.
    Static memory has no defined method of indicating failure of
    allocation, so you cannot cleanly detect and take action in
    such cases.

    If there is a failure of static memory allocation, then *some*
    systems will generate a signal that can be handled through
    the signal handling mechanism, but C89 at least does not define
    a signal for this condition and does not document it as a
    possibility, so any such signal would be an OS extension, not part of C
    itself. And in C89, if the system itself raises any of the signals
    defined specifically in C89, then behaviour of the program
    after returning from the signal handler is undefined -- all of
    the C89- defined signals are for conditions that are typically
    fatal on most operating systems. (Note: if the program itself
    used raise() to raise one of the C89- defined signals, then
    returning from the signal handler -is- well defined.)

    I would have to look up the details of the signals that C99 defines
    to see if there are any of them for which returning from the signal
    handler is well defined. C99 differs slightly from C89 in that
    there are operations (such as overflow of a signed integer) that C89
    just leaves the behaviour completely undefined, but for which C99
    says that the behaviour is undefined or that the system may optionally
    raise an implementation-defined signal. This is where the language
    lawyers make their money, arguing about the difference between
    behaviour that is -always- undefined, vs behaviour that the
    implementation may define as being undefined!
    --
    "All human knowledge takes the form of interpretation."
    -- Walter Benjamin
    Walter Roberson, May 8, 2008
    #3
  4. In article <>,
    Antoninus Twink <> wrote:

    >What's going on is that in your process's virtual address space, memory
    >is arranged like this:


    >-----------------------
    >| |
    >| STACK |
    >| (grows downwards) |
    >| |
    >-----------------------
    >| |
    >| FREE MEMORY |
    >| (available for the |
    >| stack or heap) |
    >| |
    >-----------------------
    >| |
    >| HEAP |
    >| (grows upwards) |
    >| |
    >-----------------------


    >So if you run out of free memory and overflow the stack, you can see
    >that bad things will happen.



    You truly are an amazing mind-reader! I don't know how you do it!!
    *Knowing* with certainty that the original poster is now and will
    always be using a system on which the stack grows downwards
    and the heap grows upwards.

    It doesn't happen that way in the system I'm using right now (a
    general-purpose system that at one time was the market leader in
    several different computing niches), and it doesn't happen that way
    when you start dealing with threads; and it isn't unusual for it not to
    happen that way once you start considering where -exactly- shared
    libraries get mapped into memory...

    --
    "It's a hard life sometimes and the biggest temptation is to let
    how hard it is be an excuse to weaken." -- Walter Dean Myers
    Walter Roberson, May 8, 2008
    #4
  5. On 8 May 2008 at 18:37, Walter Roberson wrote:
    > It doesn't happen that way in the system I'm using right now (a
    > general-purpose system that at one time was the market leader in
    > several different computing niches), and it doesn't happen that way
    > when you start dealing with threads; and it isn't unusual for it not to
    > happen that way once you start considering where -exactly- shared
    > libraries get mapped into memory...


    Nonetheless, as a schematic picture to have in mind, it's very valuable.
    Antoninus Twink, May 8, 2008
    #5
  6. On 8 May 2008 at 19:05, Eric Sosman wrote:
    > Not only that, he's discovered that static memory
    > is allocated on the stack!


    Ahem, yeah, good spot... Maybe it's just because static and stack sound
    alike, but certainly I read into the OP's question that he was
    contrasting dynamic and automatic allocation.
    Antoninus Twink, May 8, 2008
    #6
  7. On 8 May 2008 at 21:35, pete wrote:
    > Antoninus Twink wrote:
    >
    >> If you run out of
    >> static memory for your automatic variables,

    >
    > ITYM "static memory for your static variables,"


    ITIM "stack memory for your automatic variables"... it's been a long day
    :)
    Antoninus Twink, May 8, 2008
    #7
  8. cr88192 Guest

    <> wrote in message
    news:...
    > Which allocation (Static / Dynamic) is suitable for the situation when
    > we are trying to allocate for a overloaded memory when the memory is
    > full and no space to allocate.
    > What will happen if both the allocation is impossible.
    >


    static memory is good for fixed-memory buffers (it will never need to be
    freed or made any larger).

    however, note that static memory is also allocated as a part of the app's
    initial process image, so it will either be available, or the app will fail
    somehow early in app startup (like, an app that as soon as you try to start
    it, either the OS refuses to load it, it crashes, or the OS crashes).

    also note that, because of the fixed nature of static memory, what is
    located there can't be used by elsewhere (it is like putting a big crate in
    ones' house... one can put things in the crate, but otherwise this space is
    unusable, and would one rather have a house full of empty space, or filled
    with odd-sized crates?...).

    one is either limited by all these odd-sized crates, or all of these crates
    form a big horrible mess...


    otherwise, dynamic memory is a lot more adaptable, and I would recommend
    this as a general rule unless one has some specific reason to use large
    static buffers.

    after all, if dynamic memory were not useful, why would it have been
    implemented and used in the first place, when static memory is so much
    simpler?...


    > Sworna vidhya
    cr88192, May 9, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. s.subbarayan

    Dynamic memory allocation and memory leak...

    s.subbarayan, Mar 18, 2005, in forum: C Programming
    Replies:
    10
    Views:
    678
    Eric Sosman
    Mar 22, 2005
  2. Ken
    Replies:
    24
    Views:
    3,832
    Ben Bacarisse
    Nov 30, 2006
  3. chris
    Replies:
    6
    Views:
    971
    chris
    Oct 28, 2005
  4. Replies:
    5
    Views:
    620
    Chris Thomasson
    Aug 23, 2007
  5. Shivanand Kadwadkar

    Dynamic memory allocation with static pointer variable

    Shivanand Kadwadkar, Dec 25, 2010, in forum: C Programming
    Replies:
    7
    Views:
    2,504
    Seebs
    Jan 4, 2011
Loading...

Share This Page