Okay, I qualify this as a CS 1 question, but perhaps one that is
covered late in the semister so I'll let it slide and not kill... not
wrap hands around neck... not shake violently...
On Wed, 8 May 1996, Hades wrote:
> extract_char(ch)... in there it calls free_char(ch), which SHOULD free all
> memory used by a char, right? Then it frees the ch itself with free(ch) then
> ch = NULL; right?
[snip]
> What I really dont undertsnad is this... at the end of free_char, it sets ch
> = NULL, but in extract char I have:
> if(ch)
[snip]
> This is REALLY bugging the crap out of me... ANYONE have any ideas?
>
> Here's my free_char if it matters:
>
> void free_char(struct char_data *ch)
[snip]
> free(ch);
> ch = NULL;
> }
>
> Those last 2 lines should kill the char outta memory, even if it leaves the
> strings and such, right? Well.. I dunno... any help appreiciated.
No, this is not correct. Depending on the OS and compiler, free
could mean lots of things, but for whatever it means on your system, it
will NOT CLEAR MEMORY FOR YOU!! Think in terms of the computer. It has
this chunk of data that is pointed to by ch. You free it. What does it
mean to the computer? It means you don't want to use that chunk of data
anymore. It takes note of that. Why should it bother to zero all the
bytes? That takes work. Computers don't like to do work, because that
makes their load average go up, and high load averages make for unhappy
computers. If you want everything zeroed out, then call clear_char()
before you free() it. Then you'll be (mostly) zeroed out.
As for setting ch to NULL: that does absolutely nothing. ch is a
local variable in the function, and changes nothing outside the
function. I could tell you how to make ch equal to NULL in the way I
believe you want it to be, but you wouldn't understand it from me as well
as you would from a good C programming book. Get reading. And think
along the lines of struct char_data **ch.
--
Michael Buselli
m-buselli@uchicago.edu
http://student-www.uchicago.edu/users/mhbusell/
This archive was generated by hypermail 2b30 : 12/18/00 PST