Re: Remote protocol tune up...

[Andrew Cagney <ac131313 at cygnus dot com>]

Todd Whitesel wrote:
> 
> > regard to ``(256*1024)'', foke law has it that some hosts do not handle
> > alloca()s larger than 64k.  If you're going to allow large transfers
> > then it will need to avoid alloca().''
> 
> Alloca really should not be used for stuff that is going to get arbitrarily
> large. Many people have their stacksize limit at 8 megs or so, and some of
> the NetBSD ports (arm32, pc532, vax) have their default hard limit set at
> 8 megs also. (Not sure why they felt it necessary to do this; it may have
> been an attempt to avoid something nasty in the VM hardware.)

Some history is probably in order:

The original remote.c code had compile time PBUFSIZE constant and that
was used to allocate scratch buffers on the stack vis:

	  char buf[PBUFSIZE];

Since PBUFSIZE is small (for all known cases :-) the operation was
reasonably safe.

Then multi-arch arrived and the assumption that PBUFSIZE (based on
REGISTER_BYTES) was constant went out the window.  Fortunatly it was
still small so, the pragmatic decision was to convert the array's into
alloca() (1):

	char *buf = alloca (PBUFSIZE);

(Looking through remote.c I notice that several array style declarations
have crept back in - GCC accepts them ...).

The current proposal (and thanks to IA64 a reflection of the new
reality) is to remove the assumption that PBUFSIZE is small.  Doing this
involves xmalloc() and (*!&^#(*@!#) cleanups and incremental changes
(JimB you are not allowed to talk about GUILE :-)


As for alloca(). It stinks.  Unfortunatly it is a reliable mechanism for
allocating small arbitrary sized data that has a well defined lifetime. 
GDB typically uses a cleanup when creating a data structure that should
out live the current function;s lifetime but, if an error occures,
should be re-claimed.  Alloca gets used when the programmer knew that
the data's lifetime was determined by that of the bounding function.

Before this goes any further I think I'll just mention that it was a
Nazi that made me do it :-)
( http://www.wins.uva.nl/~mes/jarg320.old/g/GodwinsLaw.html )

	enjoy,
		Andrew



(1) If you look through the code you'll notice that multi-arch
introduced several other alloca()s but again where it was known that the
buffer involved while dynamic was small.