From: "NeoStar" <neostar@inorbit.com>
> Yes, I do have ASCII pfiles, but I thought the patch for it took care of
> all that kind of stuff
>
It did, for what it applied to. When you add stuff, you have to take those
considerations yourself.
> > written example of it, anyway. A bit of reordering is in order:
> >
> > if (load_char(argument, &tmp_store) > -1) {
> > CREATE(victim, struct char_data, 1);
> > clear_char(victim);
> > store_to_char(&tmp_store, victim);
>
> Why reorder it? The char has to be created before it can be used for
> comparisons!
In stock code, load_char() takes a name (argument) and a pointer to a
char_file_u structure. What it does with this data is get the character
information from the player file and copy it to the char_file_u struct.
So, to use load_char(), no `victim' (struct char_data *) is needed, because
it's neither an argument nor a returned-value (as can be gleaned from the
"> -1" above, load_char returns a numeric value).
CREATE() is a front-end macro for memory allocation, (without looking at the
source, I believe it actually ends up calling calloc() rather than
malloc()). Now, we have a pointer to a char_data structure which has
actually had memory allocated for it. This means, at some point, it'll have
to be free()'d as well.
clear_char(victim) simply makes sure everything is set to a default (zero)
value on the char_data struct. Technically, if I'm right about calloc(), I
think everything is zeroed already, but I could be wrong.
store_to_char(), in stock (and only in stock, the ascii player file patch
you're using doesn't have store_to_char()) copies information over from the
char_file_u (tmp_store) to the char_data struct which `victim' is a pointer
to.
The reason why one should, in this case, arrange as above, is that you don't
allocate and free memory you're not going to use, unnecessarily.
load_char() returns -1 (that should be NOBODY, but that's just a #define
of -1 anyway) on failure, so we know, once it is done, that no player was
found.
In that event, we won't allocate memory and try to get information that
isn't there.
> > BTW, this is why some wise person the other day suggested that one only
> > apply patches that one understands and can write oneself. If you don't
> > understand how they interact, you rapidly cut-and-paste yourself into a
>
> Might I remind you that, in accordance with list rules, I added a flag to
> the subject of my email, indicating it was a NEWBIE topic. You shouldn't
> expect a lot.
Except effort is expected (and encouraged).
-k.
(and aliteration is awesome!)
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST