efficient rpc io using vstr

[James Antill]

 Referrers are wonderful things, I'll try not to be too annoying with
the PR... :)

On 20 Jan 2004, Martin Pool <mbp at samba.org> wrote:
> On 20 Jan 2004, Michael B Allen <mba2000 at ioplex.com> wrote:
> > > If there is a way to get away from the security problems of char*
> > > buffers without giving up too much speed or flexibility then I think
> > > that's a good thing.
> > 
> > Yup. I agree you have to have at least a convention to keep folks from
> > doing inappropriate things.
> 
> On the Vstr web page, James says that a convention alone is not enough
> to save you, because nonconventional uses can slip through.  Samba has
> done some technical things to make it harder but it still happens.

 Even more importantly, I think Michael is at least an above average
programmer ... however my first discussion with him centered on how the
code he'd posted a link to (also a supposedly FSM) contain multiple
buffer overflows[1].

 But again, I don't hold this against Michael ... think of it like
kicking a ball in the air, almost everyone can do it once or twice but
if you need to not drop it for even 1,000 consecutive kicks that's a
much harder to thing to ask for.

 Note that I mainly try to argue with people to use some API that
stops buffer overflows, although obviously I'm biased as to which.

 And to be fair[2]...

> To fix up the path:
> 
>   size_t pos = 1;
>   while ((pos = vstr_srch_chr_fwd(path_vstr, pos, path_vstr->len, 
>                                   '\\')) != 0) {
>     vstr_sub_buf(path_vstr, pos, 1, "/", 1);
>   }
> 
> I don't think that is enormously harder than plain char*.

 This, at least, needs the change...

  size_t pos = 1;
  while ((pos = vstr_srch_chr_fwd(path_vstr, pos, 
                                  vstr_sc_posdiff(pos, path_vstr->len),
                                  '\\')) != 0) {

...and I'd also use vstr_sub_cstr_buf(), but that's mostly cosmetic[3].
 The difference is that if you ran the call with the debugging compile
of Vstr the vstr_srch_chr_fwd function would call abort(), and the
non-debugging version would just return 0 (Ie. the normal failure
code) screwing up the length you pass to memchr() on the other
hand...

 Anyway, I'll try not to butt in again...

[1] http://groups.google.com/groups?q=g:thl774496736d&selm=pan.2003.05.16.21.00.52.119697%40and.org

[2] Not forgetting that Martin has probably only seen the Vstr API for
a few weeks (or months at best).

[3] You can still overflow that buffer, but in this case it's very
very unlikely.

-- 
James Antill -- james at and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/