Overwriting Allocated Memory from malloc()

Discussion in 'C Programming' started by tweak, Jul 9, 2004.

  1. tweak

    tweak Guest

    I have been messing around with buffers, and
    I found it peculiar that the code below will
    run without a segmentation fault.

    As far as I know, overwriting the allocated space
    from a call to malloc() results in undefined
    behavior.

    Any ideas why overwriting the dynamically
    assigned space doesn't cause a segmentation
    fault?

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <errno.h>

    int
    main(void)
    {

    char *ptr = NULL;
    char buffer[256]; /* intentionally did not initialize */
    int y = 0;

    if ( ( ptr = malloc(1) ) == 0 ) {
    perror("malloc() problem");
    exit(1);
    }

    for ( int i; i < 255; i++ )
    buffer = 'Z';

    while ( (ptr[y] = buffer[y]) != '\0' )
    y++;
    (void)printf("ptr is: %s\n", ptr);
    free(ptr);

    return 0;
    }
     
    tweak, Jul 9, 2004
    #1
    1. Advertising

  2. tweak

    Eric Amick Guest

    On Thu, 08 Jul 2004 18:22:16 -0700, tweak <> wrote:

    >As far as I know, overwriting the allocated space
    >from a call to malloc() results in undefined
    >behavior.
    >
    >Any ideas why overwriting the dynamically
    >assigned space doesn't cause a segmentation
    >fault?


    Because undefined behavior by definition can be anything at all. You
    were lucky, nothing more.

    --
    Eric Amick
    Columbia, MD
     
    Eric Amick, Jul 9, 2004
    #2
    1. Advertising

  3. tweak

    Lewis Bowers Guest

    tweak wrote:

    > I have been messing around with buffers, and
    > I found it peculiar that the code below will
    > run without a segmentation fault.
    >
    > As far as I know, overwriting the allocated space
    > from a call to malloc() results in undefined
    > behavior.
    >
    > Any ideas why overwriting the dynamically
    > assigned space doesn't cause a segmentation
    > fault?


    Why would you expect undefined behavior(UB) to cause seg fault?
    To me, UB seems to suggest that anything can happen; good, bad, expected

    or unexpected.
     
    Lewis Bowers, Jul 9, 2004
    #3
  4. On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
    wrote:

    >
    >I have been messing around with buffers, and
    >I found it peculiar that the code below will
    >run without a segmentation fault.
    >
    >As far as I know, overwriting the allocated space
    >from a call to malloc() results in undefined
    >behavior.
    >
    >Any ideas why overwriting the dynamically
    >assigned space doesn't cause a segmentation
    >fault?


    Undefined behavior is not guaranteed to cause a segment fault. In its
    most pernicious form, it appears to work properly until it can satisfy
    one of Murphy's laws.

    >
    >#include <stdio.h>
    >#include <stdlib.h>
    >#include <string.h>
    >#include <errno.h>
    >
    >int
    >main(void)
    >{
    >
    > char *ptr = NULL;
    > char buffer[256]; /* intentionally did not initialize */
    > int y = 0;
    >
    > if ( ( ptr = malloc(1) ) == 0 ) {
    > perror("malloc() problem");
    > exit(1);
    > }
    >
    > for ( int i; i < 255; i++ )
    > buffer = 'Z';
    >
    > while ( (ptr[y] = buffer[y]) != '\0' )
    > y++;
    > (void)printf("ptr is: %s\n", ptr);
    > free(ptr);
    >
    > return 0;
    >}




    <<Remove the del for email>>
     
    Barry Schwarz, Jul 9, 2004
    #4
  5. tweak

    tweak Guest

    Barry Schwarz wrote:
    > On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
    > wrote:
    >
    >
    >>I have been messing around with buffers, and
    >>I found it peculiar that the code below will
    >>run without a segmentation fault.
    >>
    >>As far as I know, overwriting the allocated space

    >
    >>from a call to malloc() results in undefined

    >
    >>behavior.
    >>
    >>Any ideas why overwriting the dynamically
    >>assigned space doesn't cause a segmentation
    >>fault?

    >
    >
    > Undefined behavior is not guaranteed to cause a segment fault. In its
    > most pernicious form, it appears to work properly until it can satisfy
    > one of Murphy's laws.


    I tried different sizes of the buffer array, and I was able to generate
    a segmentation fault. Since the compiler tells me everything is okay,
    and since the software appears to work, are there any audit tools to
    check for problems like this one, where the compiler doesn't warn of
    a potential problem (beyond just the malloc() ones listed in the FAQ)?

    I'm sure you grep or use an equivalent tool in the many different
    OS's we have. But are there any portable tools?

    Of course, writing ISO C99 code that is portable is preferred, but you
    can miss stuff as the number of lines of code and number of files increase.

    Brian
     
    tweak, Jul 9, 2004
    #5
  6. "tweak" <> wrote in message news:pJpHc.787$rr.721@fed1read02...
    > Barry Schwarz wrote:
    > > On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
    > > wrote:

    [..]
    > I tried different sizes of the buffer array, and I was able to generate
    > a segmentation fault. Since the compiler tells me everything is okay,
    > and since the software appears to work, are there any audit tools to
    > check for problems like this one, where the compiler doesn't warn of
    > a potential problem (beyond just the malloc() ones listed in the FAQ)?
    >


    lint may be helpful. See below.

    > I'm sure you grep or use an equivalent tool in the many different
    > OS's we have. But are there any portable tools?
    >
    > Of course, writing ISO C99 code that is portable is preferred, but you
    > can miss stuff as the number of lines of code and number of files increase.
    >
    > Brian



    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <string.h>
    > #include <errno.h>
    >
    > int
    > main(void)
    > {
    >
    > char *ptr = NULL;
    > char buffer[256]; /* intentionally did not initialize */
    > int y = 0;
    >
    > if ( ( ptr = malloc(1) ) == 0 ) {
    > perror("malloc() problem");
    > exit(1);
    > }
    >
    > for ( int i; i < 255; i++ )


    i is uninitialized. UB.

    > buffer = 'Z';
    >
    > while ( (ptr[y] = buffer[y]) != '\0' )
    > y++;
    > (void)printf("ptr is: %s\n", ptr);
    > free(ptr);
    >
    > return 0;
    > }


    F:\>splint overflow.c
    Splint 3.0.1.6 --- 11 Feb 2002

    overflow2.c: (in function main)
    overflow2.c(15,18): Unrecognized identifier: NULL
    Identifier used in code has not been declared. (Use -unrecog to inhibit
    warning)
    overflow2.c(19,19): Unrecognized identifier: malloc
    overflow2.c(20,10): Unrecognized identifier: perror
    overflow2.c(21,10): Unrecognized identifier: exit
    overflow2.c(27,15): Index of possibly null pointer ptr: ptr
    A possibly null pointer is dereferenced. Value is either the result of a
    function which may return null (in which case, code should check it is not
    null), or a global, parameter or structure field declared with the null
    qualifier. (Use -nullderef to inhibit warning)
    overflow2.c(19,19): Storage ptr may become null
    overflow2.c(27,24): Value buffer[] used before definition
    An rvalue is used that may not be initialized to a value on some execution
    path. (Use -usedef to inhibit warning)
    overflow2.c(29,12): Unrecognized identifier: printf
    overflow2.c(30,6): Unrecognized identifier: free

    Finished checking --- 8 code warnings
     
    Vijay Kumar R Zanvar, Jul 9, 2004
    #6
  7. tweak

    tweak Guest

    Vijay Kumar R Zanvar wrote:
    > "tweak" <> wrote in message news:pJpHc.787$rr.721@fed1read02...
    >
    >>Barry Schwarz wrote:
    >>
    >>>On Thu, 08 Jul 2004 18:22:16 -0700, tweak <>
    >>>wrote:

    >
    > [..]
    >
    >>I tried different sizes of the buffer array, and I was able to generate
    >>a segmentation fault. Since the compiler tells me everything is okay,
    >>and since the software appears to work, are there any audit tools to
    >>check for problems like this one, where the compiler doesn't warn of
    >>a potential problem (beyond just the malloc() ones listed in the FAQ)?
    >>

    >
    >
    > lint may be helpful. See below.


    Thanks. I used google to find it. I will start using it tomorrow.
    I also found a splint. I will look at them both when I have more
    energy.


    >
    >
    >>I'm sure you grep or use an equivalent tool in the many different
    >>OS's we have. But are there any portable tools?
    >>
    >>Of course, writing ISO C99 code that is portable is preferred, but you
    >>can miss stuff as the number of lines of code and number of files increase.
    >>
    >>Brian

    >
    >
    >
    >>#include <stdio.h>
    >>#include <stdlib.h>
    >>#include <string.h>
    >>#include <errno.h>
    >>
    >>int
    >>main(void)
    >>{
    >>
    >> char *ptr = NULL;
    >> char buffer[256]; /* intentionally did not initialize */
    >> int y = 0;
    >>
    >> if ( ( ptr = malloc(1) ) == 0 ) {
    >> perror("malloc() problem");
    >> exit(1);
    >> }
    >>
    >> for ( int i; i < 255; i++ )

    >
    >
    > i is uninitialized. UB.


    Good catch. My source code reads as : for (int i = 0; i < 255; i++).
    I made a typo.

    Also since malloc() returns a NULL pointer on failure, the line that
    starts with if should read:

    if ( ( ptr = malloc(1) ) == NULL ) {

    to be consistent even though it's just a style thing.

    Thanks,

    Brian
     
    tweak, Jul 9, 2004
    #7
  8. tweak

    Richard Bos Guest

    tweak <> wrote:

    > > "tweak" <> wrote in message news:pJpHc.787$rr.721@fed1read02...
    > >> if ( ( ptr = malloc(1) ) == 0 ) {


    > Also since malloc() returns a NULL pointer on failure,


    No, it doesn't. It returns a null pointer. NULL is a macro, which
    expands to a null pointer _constant_, and exists only in your source
    code; a null pointer is an object, which exists during runtime.

    > the line that starts with if should read:
    >
    > if ( ( ptr = malloc(1) ) == NULL ) {
    >
    > to be consistent even though it's just a style thing.


    There's nothing consistent about it. The original is just as good, just
    as clear, and just as proper C. The only way in which this version could
    be more, rather than just as, consistent, is if you've used NULL
    everywhere else in your code; but that is consistency with _yourself_,
    not with C. C does not distinguish between those two versions; both must
    work equally well.

    Richard
     
    Richard Bos, Jul 9, 2004
    #8
  9. In 'comp.lang.c', Eric Amick <> wrote:

    > On Thu, 08 Jul 2004 18:22:16 -0700, tweak <> wrote:
    >
    >>As far as I know, overwriting the allocated space
    >>from a call to malloc() results in undefined
    >>behavior.
    >>
    >>Any ideas why overwriting the dynamically
    >>assigned space doesn't cause a segmentation
    >>fault?

    >
    > Because undefined behavior by definition can be anything at all. You
    > were lucky, nothing more.


    I'd rather have said "you were unlucky".

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jul 9, 2004
    #9
  10. In 'comp.lang.c', tweak <> wrote:

    > I have been messing around with buffers, and
    > I found it peculiar that the code below will
    > run without a segmentation fault.


    May be it's correct, who knows ?

    > As far as I know, overwriting the allocated space
    > from a call to malloc() results in undefined
    > behavior.


    Yes.

    > Any ideas why overwriting the dynamically
    > assigned space doesn't cause a segmentation
    > fault?


    Why should do it ? An undefined behaviour in unpredictable. Anything may
    happen, including a safe behaviour. Imagine you ask for 50 char. Some
    implementation could give you the address of a 64 char block. You could write
    at [50] to [63] safely.

    The problem is that you don't know about the actual safe size. The C-language
    only guarantees that the wanted size is safe. I know other implementations of
    memory allocator (PSoS) where an additional parameter is used to return the
    actual allocated size.

    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <string.h>
    > #include <errno.h>
    >
    > int
    > main(void)
    > {
    >
    > char *ptr = NULL;
    > char buffer[256]; /* intentionally did not initialize */
    > int y = 0;
    >
    > if ( ( ptr = malloc(1) ) == 0 ) {


    Should be '== NULL' to preserve reader's mental health.

    > perror("malloc() problem");
    > exit(1);


    exit (EXIT_FAILURE);

    for portability.

    > }
    >
    > for ( int i; i < 255; i++ )


    Warning, This construct only works in C99.

    > buffer = 'Z';
    >
    > while ( (ptr[y] = buffer[y]) != '\0' )


    Of course, you are overwriting the array pointed by ptr, but you know it
    already.

    > y++;


    Because 'buffer' was intentionally not initialized, there is no guarantee
    that a 0 is present at [255].

    > (void)printf("ptr is: %s\n", ptr);


    Can be anything.

    > free(ptr);
    >
    > return 0;
    > }



    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jul 9, 2004
    #10
  11. In 'comp.lang.c', "Vijay Kumar R Zanvar" <>
    wrote:

    > F:\>splint overflow.c
    > Splint 3.0.1.6 --- 11 Feb 2002
    >
    > overflow2.c: (in function main)
    > overflow2.c(15,18): Unrecognized identifier: NULL


    Sounds that your Splint is badly configured. You must teach it where to find
    the headers.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jul 9, 2004
    #11
  12. tweak

    tweak Guest

    Emmanuel Delahaye wrote:

    >
    >>#include <stdio.h>
    >>#include <stdlib.h>
    >>#include <string.h>
    >>#include <errno.h>
    >>
    >>int
    >>main(void)
    >>{
    >>
    >> char *ptr = NULL;
    >> char buffer[256]; /* intentionally did not initialize */
    >> int y = 0;
    >>
    >> if ( ( ptr = malloc(1) ) == 0 ) {

    >
    >
    > Should be '== NULL' to preserve reader's mental health.


    Correct. I was not being consistent.

    >
    >
    >> perror("malloc() problem");
    >> exit(1);

    >
    >
    > exit (EXIT_FAILURE);
    >
    > for portability.


    Now, this I am curious about. How is using EXIT_FAILURE
    more portable?

    >
    >
    >> }
    >>
    >> for ( int i; i < 255; i++ )

    >
    >
    > Warning, This construct only works in C99.


    This is a typo. It should be int i = 0;

    >
    >
    >> buffer = 'Z';
    >>
    >> while ( (ptr[y] = buffer[y]) != '\0' )

    >
    >
    > Of course, you are overwriting the array pointed by ptr, but you know it
    > already.
    >
    >
    >> y++;

    >
    >
    > Because 'buffer' was intentionally not initialized, there is no guarantee
    > that a 0 is present at [255].


    Which is why I did not initialize it. I wanted buffer to contain
    garbage. I threw in a bunch of Z's, so that I can search my registers
    to see if they were overwritten with 0x5a. The condition was just there
    to enable the while loop to insert my Z's.

    The while can continue to run, which is another problem that my compiler
    did not pick up on.

    What methods or programs are available for auditing C code?

    Thanks,

    Brian



    --
    * Remove x's to send me mail *
     
    tweak, Jul 9, 2004
    #12
  13. In 'comp.lang.c', tweak <> wrote:

    >>> exit(1);

    >>
    >> exit (EXIT_FAILURE);
    >>
    >> for portability.

    >
    > Now, this I am curious about. How is using EXIT_FAILURE
    > more portable?


    Returning values other than 0, EXIT_FAILURE or EXIT_SUCCESS to the system are
    not guaranteed to work properly.

    In your case, you return 1. Could be interpreted as the "self-destruct launch
    command" by your system, who knows... Just in case, check your system
    documentation...

    >> Because 'buffer' was intentionally not initialized, there is no guarantee
    >> that a 0 is present at [255].

    >
    > Which is why I did not initialize it. I wanted buffer to contain
    > garbage. I threw in a bunch of Z's, so that I can search my registers
    > to see if they were overwritten with 0x5a. The condition was just there
    > to enable the while loop to insert my Z's.
    >
    > The while can continue to run, which is another problem that my compiler
    > did not pick up on.
    >
    > What methods or programs are available for auditing C code?


    A real and long experience of the C language. Could be a profitable full part
    job. Some automatic tools can help (Lint or the like), but the eyes of a
    trained human are not easily replacable.

    --
    -ed- get my email here: http://marreduspam.com/ad672570
    The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
    FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
     
    Emmanuel Delahaye, Jul 9, 2004
    #13
  14. tweak <> writes:
    > Emmanuel Delahaye wrote:

    [...]
    > >> exit(1);

    > > exit (EXIT_FAILURE); for portability.

    >
    > Now, this I am curious about. How is using EXIT_FAILURE
    > more portable?


    As someone already pointed out, the only arguments to exit() that are
    guaranteed to be meaningful are 0, EXIT_SUCCESS, and EXIT_FAILURE. 0
    denotes success, but is not encessarily equal to EXIT_SUCCESS.

    A concrete example: exit(1) in VMS causes the program to return a
    status that indicates success (odd values indicate success, even
    values indicate failure). (There's special code that maps exit(0) to
    a success indication.)

    > >> for ( int i; i < 255; i++ )

    > > Warning, This construct only works in C99.

    >
    > This is a typo. It should be int i = 0;


    Which only works in C99. C90 does not allow a declaration in a for loop.

    In C99:

    for (int i = 0; i < 255; i ++)

    In C90:

    int i;
    ...
    for (i = 0; i < 255; i ++)

    (which of course will also work in C99).

    --
    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.
     
    Keith Thompson, Jul 9, 2004
    #14
  15. (Richard Bos) writes:
    > tweak <> wrote:

    [...]
    > > Also since malloc() returns a NULL pointer on failure,

    >
    > No, it doesn't. It returns a null pointer. NULL is a macro, which
    > expands to a null pointer _constant_, and exists only in your source
    > code; a null pointer is an object, which exists during runtime.


    A null pointer is a value.

    > > the line that starts with if should read:
    > >
    > > if ( ( ptr = malloc(1) ) == NULL ) {
    > >
    > > to be consistent even though it's just a style thing.

    >
    > There's nothing consistent about it. The original is just as good, just
    > as clear, and just as proper C. The only way in which this version could
    > be more, rather than just as, consistent, is if you've used NULL
    > everywhere else in your code; but that is consistency with _yourself_,
    > not with C. C does not distinguish between those two versions; both must
    > work equally well.


    That was the point; he used NULL a few lines up, in the initialization
    of ptr.

    --
    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.
     
    Keith Thompson, Jul 9, 2004
    #15
  16. tweak

    tweak Guest

    Keith Thompson wrote:
    > tweak <> writes:
    >
    >>Emmanuel Delahaye wrote:

    >
    > [...]
    >
    >>>> exit(1);
    >>>
    >>> exit (EXIT_FAILURE); for portability.

    >>
    >>Now, this I am curious about. How is using EXIT_FAILURE
    >>more portable?

    >
    >
    > As someone already pointed out, the only arguments to exit() that are
    > guaranteed to be meaningful are 0, EXIT_SUCCESS, and EXIT_FAILURE. 0
    > denotes success, but is not encessarily equal to EXIT_SUCCESS.
    >
    > A concrete example: exit(1) in VMS causes the program to return a
    > status that indicates success (odd values indicate success, even
    > values indicate failure). (There's special code that maps exit(0) to
    > a success indication.)


    Thanks. I had originally coded it with abort(), which I do not
    think is a part of ISO C99, so I replaced it with exit() for my
    example. And I should have used EXIT_FAILURE.

    This is gonna sound dumb. But what is VMS?

    >
    >
    >>>> for ( int i; i < 255; i++ )
    >>>
    >>>Warning, This construct only works in C99.

    >>
    >>This is a typo. It should be int i = 0;

    >
    >
    > Which only works in C99. C90 does not allow a declaration in a for loop.
    >
    > In C99:
    >
    > for (int i = 0; i < 255; i ++)
    >
    > In C90:
    >
    > int i;
    > ...
    > for (i = 0; i < 255; i ++)
    >
    > (which of course will also work in C99).
    >


    Thanks for clearing this up for me.

    Brian

    P.S. I code as a hobby, not as a job, so I don't have the benefit
    of working with this stuff every day.


    --
    * Remove x's to send me mail *
     
    tweak, Jul 10, 2004
    #16
  17. tweak <> writes:
    [...]
    > Thanks. I had originally coded it with abort(), which I do not
    > think is a part of ISO C99, so I replaced it with exit() for my
    > example. And I should have used EXIT_FAILURE.


    abort() is part of ISO C (both C90 and C99), but it's more drastic
    than exit().

    > This is gonna sound dumb. But what is VMS?


    VMS is an operating system. Google "VMS" for more information.

    --
    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.
     
    Keith Thompson, Jul 10, 2004
    #17
  18. "tweak" <> wrote in message news:qtmHc.148$rr.78@fed1read02...
    >
    > if ( ( ptr = malloc(1) ) == 0 ) {
    > perror("malloc() problem");


    Since malloc is not required to set errno, this may well print messages like...

    malloc() problem: no error

    Generally, such messages tend to build distrust between end users and the programs they
    use! ;)

    --
    Peter
     
    Peter Nilsson, Jul 10, 2004
    #18
  19. tweak

    tweak Guest

    Peter Nilsson wrote:
    > "tweak" <> wrote in message news:qtmHc.148$rr.78@fed1read02...
    >
    >> if ( ( ptr = malloc(1) ) == 0 ) {
    >> perror("malloc() problem");

    >
    >
    > Since malloc is not required to set errno, this may well print messages like...
    >
    > malloc() problem: no error
    >
    > Generally, such messages tend to build distrust between end users and the programs they
    > use! ;)
    >
    > --
    > Peter


    Two items:

    1) What would be the preferred way to exit a failed malloc() call? I
    will assume that would also include clean up code.

    2) Can you write code that causes malloc() to fail? I am having trouble
    doing this. I want to verify that my implementation does not set
    errno.

    Thanks,

    Brian

    P.S. I usually figure stuff out by breaking it.

    --
    * Remove x's to send me mail *
     
    tweak, Jul 10, 2004
    #19
  20. tweak

    -berlin.de Guest

    tweak <> wrote:
    > Two items:


    > 1) What would be the preferred way to exit a failed malloc() call? I
    > will assume that would also include clean up code.


    There's no prefered way, it depends solely on the application. If
    your program can't continue without the memory it probably would
    make sense to tell the user and exit. On the other hand, if the
    memory isn't that necessary and there are other ways to do what
    you want aborting the program would be overkill. And you may also
    have situations where the problem appears during some sub-task of
    the program and where you only may have to give up on running that
    sub-task but not killing the whole program. E.g. if you write a
    chess program and the user switches to a mode where the program
    tries to play very clever you might run out of memory. And in this
    case it might be nicer to tell the user that the program can't run
    with this level and that it has to switch back to a level where
    it needs less memory instead of killing the whole game.

    > 2) Can you write code that causes malloc() to fail? I am having trouble
    > doing this. I want to verify that my implementation does not set
    > errno.


    That can be difficult, depending on a lot of settings of the system
    (well you should get there if you malloc() more memory than there
    is address space...).
    <OT>
    On most UNIX-like systems you can set the maximum amount of memory a
    process may use (see ulimit or limit, depending on your shell) and
    that can really result in malloc() returning NULL.
    </OT>
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ -berlin.de
    \__________________________ http://www.toerring.de
     
    -berlin.de, Jul 10, 2004
    #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. Replies:
    5
    Views:
    662
    Matt Wharton
    Dec 9, 2004
  2. Hassan Iqbal
    Replies:
    3
    Views:
    513
    Al Bowers
    Sep 25, 2003
  3. Peter
    Replies:
    34
    Views:
    2,050
    Richard Tobin
    Oct 22, 2004
  4. Replies:
    30
    Views:
    1,509
    niraj
    Jul 3, 2011
  5. Gene
    Replies:
    0
    Views:
    465
Loading...

Share This Page