Re: RFA/RFC: vCont for the remote protocol [client]

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Oct 16, 2003 at 05:18:35PM -0400, Andrew Cagney wrote:
> 
> >Is GDB trying to move away from alloca?  The internals manual says:
> >
> >   GDB can use the non-portable function `alloca' for the allocation of
> >   small temporary values (such as strings).
> 
> >So I use it to avoid cleanups.  OTOH, it occurs to me that
> >rs->remote_packet_size is a bit large; OTOOH, remote.c uses this idiom
> >all over the place already.
> >
> >I've used xmalloc instead, since the buf is used for getpkt and thus
> >must be remote_packet_size large.
> >
> >Here's what I am about to check in.
> 
> There are two probems:
> 
> - the buffer can get very very large and that can blow the stack
> - it isn't possible to audit this code (with out a deep understanding of 
> that value) and hence demonstrate that the sprintf won't smash the 
> stack/heap
> 
> You'll need to also change the sprintf to snprintf (parameterized with 
> remote_packet_size.

I don't see a point in doing that until someone expresses interest in
thread locking or some other feature which requires adding to the code. 
The maximum length of any generated vcont packet is the length of:
   vCont;C01:12341468;C02
The minimum possible buffer size is about twenty times that.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer