Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)
Home

[Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Justin Moore <justin@xxxxxxxxxxx>
Cc: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Wed, 26 Sep 2001 23:40:26 -0400

At 07:44 PM 01/09/26 -0400, Justin Moore wrote:
>> > If, within split, I do
>> >    char *copybuf = strdup(buf);
>> > and mess around with copybuf, I'm going to parse away the first few chars
>> > of it.  args[0] != copybuf, since I've cut away the first few characters.
>> > How will I know what to free?
>>
>> I was thinking of that split() will free the copybuf.
>
>   I think I need some sample code to see how this works.  Even psuedocode
>could go a long ways.  Maybe I'm just missing something simple here.
>Given this function declaration:

Actually, having split allocate a copybuf, set return pointers into it
then free the buffer and let the caller take his chances at reading
anything useful from those pointers tends to provide job security for 
programmers, at least those other than the who actually did this. :-)

The other fun way to do this is to allocate automatic variables on the
stack and send back pointers into this. This is a good way to cover your
tracks by hiding the explicit memory management parts.

I really would let the caller manage all the memory issues, and let
split concentrate on doing the best job it can in the working memory
provided to it. The routine is called split, not malloc - that should
mean something about what its primary function is.

[...]
>- It's no worse than strtok, MM-wise, and functionally more useful.
>- The caller is responsible for strdup'ing and free'ing from within the
>    same function, which is slightly more sane than random functions
>    allocating memory within them and passing it back.
>- Allowing a restricted subset of regex-like syntax leads to fewer
>    function parameters, which is easier on the programmer.
>- My way requires no memory allocation, provided the caller is willing to
>    accept the buffer they pass in will be changed.
>
>   It seems at least one person has agreed with me so far.  I think we
>just need more people in on this, even if it's only "Raimar's right, and
>Justin's being an idiot" or vice versa. :)
>
>-jdm
>
>Department of Computer Science, Duke University, Durham, NC 27708-0129
>Email:  justin@xxxxxxxxxxx

Cheers,
RossW




[Prev in Thread] Current Thread [Next in Thread]