Ivan Todoroski <grnch@xxxxxxx> writes:
> On 27.03.2012 18:59, Junio C Hamano wrote:
>> Ivan Todoroski <grnch@xxxxxxx> writes:
>>
>>> + int alloc_heads = nr_heads;
>>> + int size = nr_heads * sizeof(*heads);
>>> + heads = memcpy(xmalloc(size), heads, size);
>>> + if (args.stateless_rpc) {
>>> + /* in stateless RPC mode we use pkt-line to read
>>> + from stdin, until we get a flush packet */
>>> + static char line[1000];
>>
>> We will never have a refname that is longer than this limit?
>
> I don't know. I grepped the code for existing usages of packet_read_line
> and that seemed to be a common idiom everywhere. Should I just bump up
> the size or is there some accepted way to read arbitrary length packets?
As you may have already guessed, you can have up to (64k - slop) bytes in
a packet. But it probably does not matter, as a loong ref that bust your
limit will not fit in the packet used in the normal codepath anyway.
>> Curious. "stop at EOF", "trim" and "skip empty" imply that you are
>> catering to people who debug this from the terminal by typing (or copy
>> pasting). Is that the expected use case?
>
> The expected use case is people using this from shell scripts that
> could be getting refs by slicing and dicing output of other commands
> with regexps and what not
That kind of use would not have leading or trailing whitespaces, and if
the target audience is scripts, I would prefer to force them to be
strict.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html