How to make malloc() fail ?

Discussion in 'C Programming' started by niranjan.singh@gmail.com, Jul 17, 2007.

  1. Guest

    This is regarding to test an SDK memory stuff.
    In what situation malloc gets fail.
    any comment/reply pls....
    regards
     
    , Jul 17, 2007
    #1
    1. Advertising

  2. santosh Guest

    wrote:
    > This is regarding to test an SDK memory stuff.
    > In what situation malloc gets fail.
    > any comment/reply pls....


    In statement:

    ptr = malloc(N);

    malloc will return NULL when it's not able to allocate N bytes of
    storage.

    Ways to force malloc to fail in it's allocation are system specific,
    so asking in an appropriate group would be more suitable.

    <OT>
    There are "stress testing" programs which can simulate a low free
    memory condition. Alternatively your operating system might have
    facilities for enforcing per user or per program quotas for memory
    allocation.
    </OT>
     
    santosh, Jul 17, 2007
    #2
    1. Advertising

  3. santosh said:

    > wrote:
    >> This is regarding to test an SDK memory stuff.
    >> In what situation malloc gets fail.
    >> any comment/reply pls....

    >
    > In statement:
    >
    > ptr = malloc(N);
    >
    > malloc will return NULL when it's not able to allocate N bytes of
    > storage.
    >
    > Ways to force malloc to fail in it's allocation are system specific,
    > so asking in an appropriate group would be more suitable.


    You see, this is what I don't like about this group. "Always with you it
    cannot be done", as Yoda rightly said.

    Okay, in the obvious sense, you're right that you can't force malloc to
    fail at your command, in the general case (requests for 0xFFFFFFFF
    bytes don't count, of course - we want a more general solution than
    that).

    But it seems to me that this isn't really what the OP wants, despite the
    wording of his question. What he wants is a software environment in
    which memory allocation failures can be simulated for testing purposes.
    And that *is* possible within ISO C. I know because I've done it, and
    quite recently too (like, within the last month or so).

    I'm not going to explain how, because I wouldn't want to distract the OP
    from focusing on the more basic skills he should be developing before
    embarking on something as intellectually challenging as programming.

    But I invite you to consider the problem yourself, as an exercise in
    creative thinking. If you trust what I say (and I suspect that you
    might), you can reason thusly: "there exists at least one solution to
    the problem of testing allocation failure paths in portable C code;
    knowing this, and knowing that I'm no fool, I ought to be able to find
    a solution myself - and maybe it will be useful in my own programming".

    You know it won't be obvious. You know it will involve a little effort.
    But you also know that, if Richard can do it, it can't be *that* hard.

    I am beginning to despair of comp.lang.c. :-(

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jul 17, 2007
    #3
  4. santosh Guest

    Richard Heathfield wrote:

    I apologise in advance if this post appears multiple times. Google has
    been wretched to use today.

    > santosh said:
    > > wrote:
    > >>
    > >> This is regarding to test an SDK memory stuff.
    > >> In what situation malloc gets fail.
    > >> any comment/reply pls....

    > >
    > > In statement:
    > >
    > > ptr = malloc(N);
    > >
    > > malloc will return NULL when it's not able to allocate N bytes of
    > > storage.
    > >
    > > Ways to force malloc to fail in it's allocation are system specific,
    > > so asking in an appropriate group would be more suitable.

    >
    > You see, this is what I don't like about this group. "Always with you it
    > cannot be done", as Yoda rightly said.
    >
    > Okay, in the obvious sense, you're right that you can't force malloc to
    > fail at your command, in the general case (requests for 0xFFFFFFFF
    > bytes don't count, of course - we want a more general solution than
    > that).
    >
    > But it seems to me that this isn't really what the OP wants, despite the
    > wording of his question. What he wants is a software environment in
    > which memory allocation failures can be simulated for testing purposes.
    > And that *is* possible within ISO C. I know because I've done it, and
    > quite recently too (like, within the last month or so).


    Yes. That's why I said "ways to force malloc", which isn't, AFAIK,
    possible within portable C. As you've noted, ways to simulate
    allocation failures *are* possible within Standard C.

    I still don't really understand exactly what the OP wants to know
    about. In hindsight, I should have pointed out to the OP that it's
    possible to simulate memory allocation failures with just Standard C,
    but since I myself usually rely on external programs for this purpose,
    the fact skipped my mind.

    <snip>

    > I am beginning to despair of comp.lang.c. :-(


    I still consider this an excellent group for C, but then again, I've
    been here only for two years, so I don't have a first hand experience
    of it's heydays.
     
    santosh, Jul 17, 2007
    #4
  5. "" <> writes:
    > This is regarding to test an SDK memory stuff.
    > In what situation malloc gets fail.


    The C standard says that malloc can fail (and if so, it returns a null
    pointer); it doesn't say under what circumstnaces it can fail.

    Realistically, it should fail if there isn't enough memory available
    for the requested allocation; you could either run out of memory on
    the system, or use up the memory allocated to your program (or
    process, or whatever).

    If you're trying to *cause* malloc to fail, the obvious way to do it
    is to request some huge amount of memory, repeatedly if necessary.
    There are two problems with this approach.

    First, if you're on a multi-user or multi-processing system, doing so
    could interfere with other users and/or other processes.

    Second, on some systems (I think Linux is an example), malloc doesn't
    actually indicate failure if it can't allocate the requested memory.
    Instead, it allocates a range of addresses to your program without
    actually allocating the memory. The memory is only allocated when you
    attempt to access it. At that point, it's too late to indicate a
    simple allocation failure, and the OS responds by killing processes.
    This behavior is arguably non-conforming.


    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jul 17, 2007
    #5
  6. Keith Thompson wrote:
    > Second, on some systems (I think Linux is an example), malloc doesn't
    > actually indicate failure if it can't allocate the requested memory.
    > Instead, it allocates a range of addresses to your program without
    > actually allocating the memory. The memory is only allocated when you
    > attempt to access it. At that point, it's too late to indicate a
    > simple allocation failure, and the OS responds by killing processes.
    > This behavior is arguably non-conforming.


    Disclaimer: I'm assuming the behaviour you described violates the standard.

    Linux by default behaves that way, but it can be configured to behave in a
    conforming manner. I know conforming implementations are allowed to have
    non-conforming modes so long as at least one mode conforms to the standard,
    but I'm curious, would they be required to clearly document to appropriate
    sysctl?
     
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 17, 2007
    #6
  7. Keith Thompson said:

    <snip>

    > If you're trying to *cause* malloc to fail, the obvious way to do it
    > is to request some huge amount of memory, repeatedly if necessary.


    Fortunately, there is also at least one non-obvious way. :)

    (And yes, it involves cheating, but *not* by resorting to non-portable
    code.)

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jul 17, 2007
    #7
  8. user923005 Guest

    On Jul 17, 4:03 am, Richard Heathfield <> wrote:
    > santosh said:
    >
    > > wrote:
    > >> This is regarding to test an SDK memory stuff.
    > >> In what situation malloc gets fail.
    > >> any comment/reply pls....

    >
    > > In statement:

    >
    > > ptr = malloc(N);

    >
    > > malloc will return NULL when it's not able to allocate N bytes of
    > > storage.

    >
    > > Ways to force malloc to fail in it's allocation are system specific,
    > > so asking in an appropriate group would be more suitable.

    >
    > You see, this is what I don't like about this group. "Always with you it
    > cannot be done", as Yoda rightly said.
    >
    > Okay, in the obvious sense, you're right that you can't force malloc to
    > fail at your command, in the general case (requests for 0xFFFFFFFF
    > bytes don't count, of course - we want a more general solution than
    > that).
    >
    > But it seems to me that this isn't really what the OP wants, despite the
    > wording of his question. What he wants is a software environment in
    > which memory allocation failures can be simulated for testing purposes.
    > And that *is* possible within ISO C. I know because I've done it, and
    > quite recently too (like, within the last month or so).
    >
    > I'm not going to explain how, because I wouldn't want to distract the OP
    > from focusing on the more basic skills he should be developing before
    > embarking on something as intellectually challenging as programming.
    >
    > But I invite you to consider the problem yourself, as an exercise in
    > creative thinking. If you trust what I say (and I suspect that you
    > might), you can reason thusly: "there exists at least one solution to
    > the problem of testing allocation failure paths in portable C code;
    > knowing this, and knowing that I'm no fool, I ought to be able to find
    > a solution myself - and maybe it will be useful in my own programming".
    >
    > You know it won't be obvious. You know it will involve a little effort.
    > But you also know that, if Richard can do it, it can't be *that* hard.
    >
    > I am beginning to despair of comp.lang.c. :-(


    I use this to create low memory situations.
    You can do it all in a big clump, or start lots of them with smaller
    mouthfuls.
    Of course, to find the exact failure point, a binary search is what is
    wanted.

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    static char string[32767];
    int main(int argc, char **argv)
    {
    size_t megabytes = 1024u * 1024u;
    size_t megs = 256;
    size_t memreq;
    char *waster;
    if (argc > 1)
    megs = atoi(argv[1]);
    if (megs == 0)
    megs = 256;

    memreq = megs * megabytes;
    waster = malloc(memreq);
    if (waster == NULL) {
    puts("Memory allocation failed");
    } else {
    printf("Press the <Enter> key to release %u megs memory\n",
    (unsigned) megs);
    fgets(string, sizeof string, stdin);
    free(waster);
    }
    return 0;
    }
     
    user923005, Jul 18, 2007
    #8
  9. user923005 said:

    <snip>

    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <string.h>
    > static char string[32767];
    > int main(int argc, char **argv)
    > {
    > size_t megabytes = 1024u * 1024u;


    1024u * 1024u is not guaranteed to fit in a size_t, so you might end up
    with a lower value therein (e.g. 0, if size_t is 16 bits).

    > size_t megs = 256;
    > size_t memreq;
    > char *waster;
    > if (argc > 1)
    > megs = atoi(argv[1]);


    I recommend strtoul(argv[1], NULL, 10) instead of atoi(argv[1]).

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jul 18, 2007
    #9
  10. Daniel Rudy Guest

    At about the time of 7/17/2007 3:36 AM, stated
    the following:
    > This is regarding to test an SDK memory stuff.
    > In what situation malloc gets fail.
    > any comment/reply pls....
    > regards
    >


    something like this:

    ptr = malloc(0xFFFFFFFF);

    That will usually cause the allocation to fail...it might also cause the
    host OS to abort the program too. I know that FreeBSD does not give a
    failure indication, the OS kills the program.

    --
    Daniel Rudy

    Email address has been base64 encoded to reduce spam
    Decode email address using b64decode or uudecode -m
     
    Daniel Rudy, Jul 18, 2007
    #10
  11. Doug Guest

    On Jul 17, 12:03 pm, Richard Heathfield <> wrote:
    > santosh said:
    >
    > > wrote:
    > >> This is regarding to test an SDK memory stuff.
    > >> In what situation malloc gets fail.
    > >> any comment/reply pls....

    >
    > > In statement:

    >
    > > ptr = malloc(N);

    >
    > > malloc will return NULL when it's not able to allocate N bytes of
    > > storage.

    >
    > > Ways to force malloc to fail in it's allocation are system specific,
    > > so asking in an appropriate group would be more suitable.

    >
    > You see, this is what I don't like about this group. "Always with you it
    > cannot be done", as Yoda rightly said.
    >


    <snip>

    > I'm not going to explain how, because I wouldn't want to distract the OP
    > from focusing on the more basic skills he should be developing before
    > embarking on something as intellectually challenging as programming.


    You see, this is what I don;t like about this group. "Always with you
    it must be condescending."

    I'm not sure why you feel you have to comment on the ability of the
    OP. Stinks of pure arrogance to me.

    What is clc for, if not to ask questions? You yourself have said this
    was on-topic. Why not give an answer, instead of your usual b.s. "I
    know but I'm not telling you"?

    Please get over yourself. If you're not going to help, be quiet. And
    please stop answering spam.

    To the OP - this can be done, but is probably best done in a platform-
    specific manner. Try asking in a group specific to your platform, or
    come back if you want a general solution.

    Doug

    P.S. My apologies if someone else is posting in RH's name
     
    Doug, Jul 18, 2007
    #11
  12. Doug said:

    > On Jul 17, 12:03 pm, Richard Heathfield <> wrote:
    >>
    >> > wrote:
    >> >> This is regarding to test an SDK memory stuff.
    >> >> In what situation malloc gets fail.
    >> >> any comment/reply pls....

    >>

    <snip>
    >
    >> I'm not going to explain how, because I wouldn't want to distract the
    >> OP from focusing on the more basic skills he should be developing
    >> before embarking on something as intellectually challenging as
    >> programming.

    >
    > You see, this is what I don;t like about this group. "Always with you
    > it must be condescending."
    >
    > I'm not sure why you feel you have to comment on the ability of the
    > OP. Stinks of pure arrogance to me.


    Well, it wasn't intended that way, but how you interpret it is your
    affair, not mine.

    > What is clc for, if not to ask questions?


    It's for discussions about C programming. The whole question-answer
    thing is, in my view, merely one way in which discussions start. It is
    true that it happens to be the most common way. But if it were not,
    then some other way would be, and by your apparent reasoning we'd all
    presume /that/ way best to describe the raison d'etre of this group.

    > You yourself have said this
    > was on-topic. Why not give an answer, instead of your usual b.s. "I
    > know but I'm not telling you"?


    Usual? It is actually quite rare for me to answer in such a way, as you
    ought to know if you believe yourself to be in a position to comment on
    my "usual" style. If you truly believe that what I usually post is
    "b.s.", then would it not have made sense for you to killfile me a long
    time ago?

    > Please get over yourself. If you're not going to help, be quiet.


    1) I have the same freedom to post here as anyone else.
    2) I didn't see you providing an answer to his question, so your
    position is somewhat hypocritical, is it not?
    3) (This is the one you won't believe, but so be it.) I *was* actually
    trying to help the OP, by suggesting that he focuses on developing his
    ability to express his ideas cogently; if he takes my advice, this will
    have a very positive effect on his ability to write computer programs.

    > And please stop answering spam.


    It is true that I occasionally post replies to spam, although it is
    rare. I have the same freedom to do that as you have to ask me to stop.
    I rarely use that freedom, but yes, I do use it sometimes. That's up to
    me. If you don't like what I write, well, that's up to you.

    And now I have my own suggestion to make to you: if you must tell other
    people how to behave, it might be as well for you to be prepared for
    the possibility that those others might not see the world the way you
    do. For example, you say you found my tone arrogant, and yet I know
    that I did not intend to convey arrogance. That suggests that I may
    need to pay closer attention to my tone. Likewise, however, I found
    your reply to be self-serving, hypocritical, and non-constructive. If
    that was not the kind of reply you intended to write, perhaps you, too,
    need to pay closer attention to your tone.

    I am not aware that you have been particularly active in providing help
    to those who seek it in this forum, or that you have contributed very
    much to the discussions here in comp.lang.c. It's easy to snipe from
    the sidelines. If you want me to take your criticisms seriously, *get
    involved*. Taking part in discussions, answering questions, getting
    tangled up in amicable fights about C, and taking one's lumps when one
    gets it wrong, are all part of the rough and tumble of daily
    comp.lang.c life, and those who are actively involved are far more
    likely to be taken seriously than those who are not.

    >
    > To the OP - this can be done, but is probably best done in a platform-
    > specific manner. Try asking in a group specific to your platform, or
    > come back if you want a general solution.


    <sarcasm>Very good.</sarcasm> And what did that add to what has already
    been said elsethread?

    > Doug
    >
    > P.S. My apologies if someone else is posting in RH's name


    This P.S. suggests that you are perfectly well aware that my "usual"
    tone is not what you claimed it to be, earlier in your article.

    FCOL, furrfu, etc.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jul 18, 2007
    #12
  13. santosh Guest

    On Wednesday 18 Jul 2007 1:15 pm, in comp.lang.c, Daniel Rudy
    <> wrote:
    Message ID: <Cyjni.9381$>

    > At about the time of 7/17/2007 3:36 AM,
    > stated the following:
    >> This is regarding to test an SDK memory stuff.
    >> In what situation malloc gets fail.
    >> any comment/reply pls....
    >> regards
    >>

    >
    > something like this:
    >
    > ptr = malloc(0xFFFFFFFF);
    >
    > That will usually cause the allocation to fail...


    Many modern workstations have 4 Gb or more of memory installed.

    > it might also cause the
    > host OS to abort the program too. I know that FreeBSD does not
    > give a failure indication, the OS kills the program.


    That's why it's not possible within ISO C to cause malloc to reliably
    fail. However you can use support code to simulate memory allocation
    failures. The support code can be portable C.
     
    santosh, Jul 18, 2007
    #13
  14. santosh wrote:
    > On Wednesday 18 Jul 2007 1:15 pm, in comp.lang.c, Daniel Rudy
    > <> wrote:
    > Message ID: <Cyjni.9381$>
    >
    >>At about the time of 7/17/2007 3:36 AM,
    >>stated the following:
    >>
    >>>This is regarding to test an SDK memory stuff.
    >>>In what situation malloc gets fail.
    >>>any comment/reply pls....
    >>>regards
    >>>

    >>
    >>something like this:
    >>
    >>ptr = malloc(0xFFFFFFFF);
    >>
    >>That will usually cause the allocation to fail...

    >
    >
    > Many modern workstations have 4 Gb or more of memory installed.
    >

    replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
    <stdint.h>; size_t is not guaranteed to be unsigned), that's more
    portable anyway - 64bit machines are real-world things already.

    Other point if you actually want libc's malloc to fail or if you want to
    verify the application's response to a failing malloc. for the latter
    case try replacing libc's malloc by another function implementing the
    same interface. There are ways to do so without or with little
    modifications to the tested code.

    bm
    --
    Bernhard Mueller
    bernhard dot mueller at
     
    =?ISO-8859-1?Q?Bernhard_M=FCller?=, Jul 22, 2007
    #14
  15. Flash Gordon Guest

    Bernhard Müller wrote, On 22/07/07 20:24:

    <snip>

    > replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
    > <stdint.h>; size_t is not guaranteed to be unsigned),


    Actually, it *is* guaranteed to be unsigned. This is why you have
    SIZE_MAX but not SIZE_MIN.
    --
    Flash Gordon
     
    Flash Gordon, Jul 22, 2007
    #15
  16. Flash Gordon wrote:
    > Bernhard Müller wrote, On 22/07/07 20:24:
    >
    > <snip>
    >
    >> replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
    >> <stdint.h>; size_t is not guaranteed to be unsigned),

    >
    > Actually, it *is* guaranteed to be unsigned. This is why you have
    > SIZE_MAX but not SIZE_MIN.


    It is guaranteed to be an unsigned integer type, which might or might not be
    the type specified by "unsigned" (aka "unsigned int").
     
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 22, 2007
    #16
  17. Flash Gordon Guest

    Harald van Dijk wrote, On 22/07/07 21:08:
    > Flash Gordon wrote:
    >> Bernhard Müller wrote, On 22/07/07 20:24:
    >>
    >> <snip>
    >>
    >>> replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
    >>> <stdint.h>; size_t is not guaranteed to be unsigned),

    >> Actually, it *is* guaranteed to be unsigned. This is why you have
    >> SIZE_MAX but not SIZE_MIN.

    >
    > It is guaranteed to be an unsigned integer type, which might or might not be
    > the type specified by "unsigned" (aka "unsigned int").


    I meant an unsigned type, not unsigned int. I should have been clear.
    --
    Flash Gordon
     
    Flash Gordon, Jul 22, 2007
    #17
  18. Flash Gordon wrote:
    > Harald van Dijk wrote, On 22/07/07 21:08:
    >> Flash Gordon wrote:
    >>> Bernhard Müller wrote, On 22/07/07 20:24:
    >>>
    >>> <snip>
    >>>
    >>>> replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
    >>>> <stdint.h>; size_t is not guaranteed to be unsigned),
    >>> Actually, it *is* guaranteed to be unsigned. This is why you have
    >>> SIZE_MAX but not SIZE_MIN.

    >>
    >> It is guaranteed to be an unsigned integer type, which might or might not
    >> be the type specified by "unsigned" (aka "unsigned int").

    >
    > I meant an unsigned type, not unsigned int. I should have been clear.


    I know that's what you meant. I meant that it doesn't necessarily contradict
    Bernhard Müller's claim.
     
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 23, 2007
    #18
  19. Army1987 Guest

    On Mon, 23 Jul 2007 06:55:54 +0200, Harald van Dijk wrote:

    > Flash Gordon wrote:
    >> Harald van Dijk wrote, On 22/07/07 21:08:
    >>> Flash Gordon wrote:
    >>>> Bernhard Müller wrote, On 22/07/07 20:24:
    >>>>
    >>>> <snip>
    >>>>
    >>>>> replace 0xFFFFFFFF with (size_t)-1 or the macro SIZE_MAX (from
    >>>>> <stdint.h>; size_t is not guaranteed to be unsigned),
    >>>> Actually, it *is* guaranteed to be unsigned. This is why you have
    >>>> SIZE_MAX but not SIZE_MIN.
    >>>
    >>> It is guaranteed to be an unsigned integer type, which might or might not
    >>> be the type specified by "unsigned" (aka "unsigned int").

    >>
    >> I meant an unsigned type, not unsigned int. I should have been clear.

    >
    > I know that's what you meant. I meant that it doesn't necessarily contradict
    > Bernhard Müller's claim.

    Even if size_t is an unsigned type other than unsigned int,
    malloc((size_t)(-1)) does the same as malloc(SIZE_MAX). So I don't think
    he meant size_t needn't be the type unsigned int, or the mention
    of that macro would be irrelevant.

    --
    Army1987 (Replace "NOSPAM" with "email")
    "Never attribute to malice that which can be adequately explained
    by stupidity." -- R. J. Hanlon (?)
     
    Army1987, Jul 24, 2007
    #19
  20. Army1987 Guest

    On Tue, 17 Jul 2007 13:20:07 -0700, Keith Thompson wrote:
    > If you're trying to *cause* malloc to fail, the obvious way to do it
    > is to request some huge amount of memory, repeatedly if necessary.
    > There are two problems with this approach.

    [snip]
    > Second, on some systems (I think Linux is an example), malloc doesn't
    > actually indicate failure if it can't allocate the requested memory.
    > Instead, it allocates a range of addresses to your program without
    > actually allocating the memory. The memory is only allocated when you
    > attempt to access it. At that point, it's too late to indicate a
    > simple allocation failure, and the OS responds by killing processes.
    > This behavior is arguably non-conforming.

    I think it also depends on the size of the blocks.
    For example on my system (Ubuntu 6.10 with 1GB RAM and 1GB swap
    partition)
    #include <stdlib.h>
    #include <stdio.h>
    int main(void)
    {
    unsigned long i;
    size_t size = 2000000000;
    for (i = 0; malloc(size); i++)
    continue;
    printf("%.7g kilobytes\n", i * (size / 1024.0));
    return 0;
    }
    prints 0 if size is very large, about 3 GB if it is between
    approx. 10000 and 1000000, and gets eventually killed if it is
    very small.
    --
    Army1987 (Replace "NOSPAM" with "email")
    "Never attribute to malice that which can be adequately explained
    by stupidity." -- R. J. Hanlon (?)
     
    Army1987, Jul 24, 2007
    #20
    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. Wenjie

    if (f() != FAIL) or if (FAIL != f())?

    Wenjie, Jul 28, 2003, in forum: C Programming
    Replies:
    3
    Views:
    473
    E. Robert Tisdale
    Jul 31, 2003
  2. Chess Saurus

    Can malloc ever really fail?

    Chess Saurus, Jul 21, 2004, in forum: C Programming
    Replies:
    27
    Views:
    861
    Keith Thompson
    Jul 27, 2004
  3. Re: Can malloc ever really fail?

    , Jul 21, 2004, in forum: C Programming
    Replies:
    26
    Views:
    647
    RoSsIaCrIiLoIA
    Jul 25, 2004
  4. John
    Replies:
    13
    Views:
    723
  5. The Doctor

    malloc() fail

    The Doctor, Sep 21, 2008, in forum: C++
    Replies:
    10
    Views:
    2,436
    James Kanze
    Sep 28, 2008
Loading...

Share This Page