Re: [RFC/PATCH] pkt-line: allow writing of LARGE_PACKET_MAX buffers

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote:
>
>> Another option would be to use a static strbuf. Then we're only wasting
>> heap, and even then only as much as we need (we'd still manually cap it
>> at LARGE_PACKET_MAX since that's what the protocol dictates). This would
>> also make packet_buf_write more efficient (right now it formats into a
>> static buffer, and then copies the result into a strbuf; probably not
>> measurably important, but silly nonetheless).
>
> Below is what that would look like. It's obviously a much more invasive
> change, but I think the result is nice.

Yes, indeed.  Is there any reason why we shouldn't go with this
variant, other than "it touches a bit more lines" that I am not
seeing?

> Let's switch to using a strbuf, with a hard-limit of
> LARGE_PACKET_MAX (which is specified by the protocol).  This
> matches the size of the readers, as of 74543a0 (pkt-line:
> provide a LARGE_PACKET_MAX static buffer, 2013-02-20).
> Versions of git older than that will complain about our
> large packets, but it's really no worse than the current
> behavior. Right now the sender barfs with "impossibly long
> line" trying to send the packet, and afterwards the reader
> will barf with "protocol error: bad line length %d", which
> is arguably better anyway.

Anything older than 1.8.3 is affected by this, but only when the
sending side has to send a large packet.  It is between failing
because the sender cannot send a large packet and failing because
the receiver does not expect such a large packet to come, and either
way the whole operation will fail anyway, so there is no net loss.