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: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)
From: Justin Moore <justin@xxxxxxxxxxx>
Date: Sun, 23 Sep 2001 17:59:48 -0400 (EDT)

> >  
> > /***************************************************************************
> > +  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.

> > +
> > +  Return the number of sub-elements found.
> > +***************************************************************************/
> > +int split(char *toks, char *buf, char **args, int max_args)
>
> Can you please add some consts. Yes I know that const isn't used much
> in freeciv. But this method is more like the str* method.

   *nod*

> > +{
> > +  int i;
> > +  int nfound;
> > +  int len;
> > +  char *my_toks;
> > +
>
> > +  if((buf[0] == '#') || (buf[0] == '\n')) /* Comment or blank line */
> > +    return 0;
>
> The handling of comments should be in this general purpose method.

   Which general purpose method?

> > +
>
> > +  /* Remove all leading whitespace and toks.
>
> Please mention this in the header.

   *nod*

> 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?

-jdm

"You don't give blood then take it back again
 We're all deserving of something more"
 - "Grievance"

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx



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