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: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 24 Sep 2001 09:18:17 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Sep 23, 2001 at 05:59:48PM -0400, Justin Moore wrote:
> 
> > >  
> > > /***************************************************************************
> > > +  PERL-like split.  Takes a string of characters to split on, a buffer to
> > > +  split, and an array of pointers to return.  Can set a max size on the
> >
> > It returns an int. It may fill/write an array of pointers.
> 
>    Er, right.  s/"to return"/"fill in"/g.
> 
> > > +  NOTE: This WILL change the original buffer, so if you want an original
> > > +        copy of it, make it before you pass it to this function.
> >
> > Can you please remove this restriction.
> 
>    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?

> > The handling of comments should be in this general purpose method.

I'm sorry: s/should/shouldn't/

> 
>    Which general purpose method?

cut_comment

> > What about memory management? Who allocates the space for args? The
> > caller or split? It looks like args are currently pointers to buf. I
> > don't like this.
> 
>    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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  Microsoft does have a year 2000 problem. I'm part of it. I'm running Linux.


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