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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Sep 24, 2001 at 08:14:19PM -0400, Justin Moore wrote:
> 
> > >    Not very easily.  The options are to a) have the caller malloc a copy
> > > of the string and pass it in, or b) malloc X buffers of unknown size ahead
> > > of time and pass those in.  The memory management gets tricky.
> >
> > What about a strdup() in split?
> 
>    I could, but I really think all memory allocation and de-allocation
> should be done at the same level, so-to-speak.

What is the problem? split() will strdup() the string it gets and
frees it copy later.

> I've never been a big fan
> of strdup.  I'd like to get other people's opinions on this (especially
> since I see no compelling reason to do this, but I know it won't get into
> CVS until it gets your approval ;p).
> 
> > >    Which general purpose method?
> >
> > cut_comment
> 
>    *nod*
> 
> > >    It is up to the caller to allocate the array of pointers.  And, yes,
> > > they are pointers to buf.  Otherwise it becomes a nightmare trying to do
> > > several small mallocs and frees along the way.  I'm open to suggestions on
> > > another way to do this, but I find it just easier to accept the fact that
> > > the original buffer you pass in will be modified.  If you want an original
> > > copy of it, make it before you call split.  How is this restriction bad?
> >
> > Either the caller allocates the memory and pass the size down to split:
> >
> > char buffer[10][50];
> > ...
> > split(...,buffer,10,50);
> >
> > or split allocates the memory and the caller has the free it.
> >
> > char *strings[10];
> > ...
> > n=split(...,strings,10);
> > ...
> > for(i=0;i<n;i++)
> >    free(strings[i]);
> >
> > IMHO the first one is nicer.
> 
>    I agree.  But I don't think we should place limitations on the size of
> the buffer(s) in split, which is what your version does.
> 
>    On a side note, I'm going to remove the "automatically removes
> whitespace" implementation, and require the caller to pass a "\S" as a
> token if they want to split on whitespace.  If they want to remove
> whitespace surrounding other split tokens, they would pass in a "\s".  A
> "\S" implies "\s".
> 
> split("\s,", buf, args, 5);
> 
> will correctly parse
> 
> Alphabet,Iron Working,Pottery, The Wheel
> 
> Comments?

I would rather like to see this explicitly as an argument of split.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "This is Linux Country. On a quiet night, you can hear Windows reboot."