Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: dynamic timeout (PR#1356)
Home

[Freeciv-Dev] Re: dynamic timeout (PR#1356)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: dynamic timeout (PR#1356)
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 7 Apr 2002 22:34:39 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Sun, Apr 07, 2002 at 03:27:25PM -0500, Mike Kaufman wrote:
> On Sun, Apr 07, 2002 at 09:48:24PM +0200, Raimar Falke wrote:
> > On Sun, Apr 07, 2002 at 10:45:31AM -0500, Mike Kaufman wrote:
> > > On Sun, Apr 07, 2002 at 02:50:40PM +0200, Raimar Falke wrote:
> > > > > +***************************************************************/
> > > > > +void get_args(char *str, char **args, int numargs)
> > > > 
> > > > Please pass in the maximum size.
> > > 
> > > I do not understand. str's maximum size? why? 
> > > numargs should be <= the size of the args array. I don't see why we need
> > > anything else. Please be explicit.
> > 
> > *rereading the patch* I misunderstood it. Neither the caller nor the
> > callee allocate memory but the args pointers point into the original
> > string. Uhhh. Such pointer aliasing should IMHO be avoided. This
> > construct

This is IMHO a quite nice solution for the memory problem:

> >    char str[MAX_LEN];

-    char *args[numargs];
+    char args[numargs][SOME_MAX_LEN];

> > 
> >    sz_strlcpy(str, buffer);

-    get_args(str, args, numargs);
+    get_args(str, args, numargs, sizeof(args[0]));

> > will also change args[0][0]. This isn't intuitive.
> 
> I want 1. a single call 2. that's easy to use. I suppose that you want
> to start allocating memory for these pointers... My opinion is that
> you're already taking a risk by changing str. If the coder screws himself
> by changing str _after_ the call, that's his own damn fault.
> 
> Give me a better reason than "aliasing should IMHO be avoided".
> The question is: are we ever going to depend on that memory staying
> around? The answer is perhaps. I'll think about it.

> > > These are not analogous situations. cut_comment merely looks for paired
> > > sets before it gets to the octothorp. Here we've got to keep track of
> > > everything. Besides, I want to be able to create players like:
> > > create "ain't I cool" "don't mess with me" 
> > > which won't work if apostrophes are special. (of course we could expect
> > > the user to \', but now we expect the user to use double quotes, either
> > > way the user has some responsibility)
> > 
> > And want to allow a player name 'Joe "The Hammer" User'
> 
> I'm not sure that you know what kind of a nightmare you're getting
> yourself into.

The parsing? That this may open security issues? That users may abuse
this?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "At the beginning of the week, we sealed ten BSD programmers
  into a computer room with a single distribution of BSD Unix.
  Upon opening the room after seven days, we found all ten programmers 
  dead, clutching each other's throats, and thirteen new flavors of BSD."


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