Re: RFA: patch to remote.c for larger download packet support (part 1)

[Andrew Cagney <ac131313 at cygnus dot com>]

"Frank Ch. Eigler" wrote:

I've the same general concern that J.T. raised.  The operation should be
more robust and the user problably better informed.

While on that, I suspect that there is an old bug in there.  Eyeballing
the code suggests that the user can set the remote_packet_size to
something negative.....  Extra test?

Consequently, could I suggest breaking the patch down.

Fix the remote_write_size so that it is checked and the user informed if
it exceeds certain bounds (<= 0, > PBUFSIZE - ``that Q@$&)(!*$& 5''?). 
Consistent with the ``set remote packet'' command it should have an
``auto'' mode where it picks up the PBUFSIZE value.  It would also need
to handle multi-arch which can change PBUFSIZE under your feet.  I
suspect that it will lead to the elimination of min() calls and the
replacement of several macro's with statics.

With that in place, a separate patch to allow very large and possibly
infinite (hey, why set an arbitrary limit? :-) packet sizes.  With
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().

	enjoy,
		Andrew