nnrpd's Argify() and passwords with spaces

Jeffrey M. Vinocur jeff at litech.org
Thu Dec 20 06:57:27 UTC 2001


On 19 Dec 2001, Russ Allbery wrote:

> One thing that you may want to look at if you're rewriting code in this
> area is the new vector interface I added to libinn in CURRENT.

Ooh.  Yes.


> I don't think there are any current split functions for vectors that match
> this (split out the first n), but that's obviously generally useful and it
> should be reasonably straightforward to add.

Nope...will look at this, then.  After new year's, most likely.


Out of curiosity...any reason you didn't do the resizing by a
multiplicative factor (to get amortized constant time)?

(I find myself writing dynamically-growing array-thingees far too often;
my preference is to grow from i to 2*i+1 (the +1 is to avoid having to
special-case for size==0) and possibly provide a compact() in the
interface to be called when the insertions are done to resize to exactly
the right size, if memory wastage is an issue.)


> > and add the following two functions (after which Argify can be defined
> > as a wrapper around nArgify with n=-1 for backwards compatibility):
>
> Yeah, if you're going to this sort of work, definitely take a look at
> vector (the interface is in include/inn/vector.h).  I think the new code
> should be simpler and easier to work with.

Right.  (The old code actually wasn't that bad, as far as any function
that has *** in its prototype can be.)


> I think the vector interface may force a somewhat different decision here,
> since you really want to return a new vector.

*thinks*

Are you sure?  I was satisfied with the way the further-parsing-in-place
worked out -- no efficiency hit versus the all-at-once Argify (except for
function call overhead and such).

Well, come to think of it, you might need different behavior for vectors
and cvectors.  For cvectors, you certainly could split in place and it
would probably be more in the spirit for them.  For regular vectors, it
feels like it should be returning a new vector, but then (as I gather from
the interface, which I just glanced at) you'd have to duplicate all of the
already-parsed substrings...seems silly.  (On the other hand, it means
that you can have both the parsed version and any semi-parsed segment
available at the same time.  But I don't know if it's worth it.)


> That argues for doing the latter, since the number of items you split
> things into is already stored in the vector as the vector length.

Agreed.


-- 
Jeffrey M. Vinocur
jeff at litech.org



More information about the inn-workers mailing list