Re: Non-Oasis OLC

From: Daniel A. Koepke (dkoepke@california.com)
Date: 12/30/99


On Thu, 30 Dec 1999, Chris Gilbert wrote:

> Warren Robbins wrote:
> >
> > Maybe if I was somehow allowing my strings to be free()'d, that would be a
> > problem, but I'm not NULLing anything out.
>
> That could be why, the old strings are still in memory.  Oasis 2 gets
> around this by updating all mobs/objs that are loaded with ptrs to the
> strings after the updated prototype is inserted.  You may find you've
> got a memory leak if you're not freeing the old memory.

And, not entirely for the sake of pedanticism but not directly related, it
should be mentioned that free() does not, as Warren implied, NULL anything
out.  It frees the memory at a specified address -- it does not change the
address that the pointer points to.  I.e., if we have a hypothetical
pointer 'ptr' which points to memory address 0x400d4a78, and 0x400d4a78
has "sizeof(char) * 32" bytes allocated to it (note that sizeof(char) is
just 1, but it doesn't hurt to be verbose), calling free(ptr); just says
that the memory at 0x400d4a78 is no longer valid.  It DOES NOT change the
fact that ptr points to 0x400d4a78; or, even, what 0x400d4a78 contains.
The latter might be (probably is?) implementation specific -- GNU C
doesn't seem to zero out memory at the given address to free(); the former
is standard.

Thus,

    ptr = calloc(27, sizeof(char));
    strcpy (ptr, "abcdefghijklmnopqrstuvwxyz");
    printf("(%p %s)\r\n", ptr, ptr);
    free(ptr);
    if (ptr) printf("(%p %s)\r\n", ptr, ptr);

will print out something like,

    (0x400d4a78 abcdefghijklmnopqrstuvwxyz)
    (0x400d4a78 abcdefghijklmnopqrstuvwxyz)

on GNU C.  Why this works is beyond the scope of this posting, but suffice
it to say it's not something you should do.  The point is to reinforce to
the list -- and I've said it a great many times before -- that you should
NEVER trust free() to do anything but remove the specified memory address
from the program's list of allocated memory space.

Those using glibc 2.x or Linux libc 5.4.23 or later who want to see how
well they're handling memory should set MEMORY_CHECK_ to 1 to enable less
efficient, but much-better-at-catching-errors version of malloc(),
calloc(), realloc(), and free().

-dak


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/15/00 PST