Brandon Williams wrote:
> On 02/12, Jonathan Nieder wrote:
>>> --- a/pkt-line.h
>>> +++ b/pkt-line.h
>>> @@ -111,6 +111,64 @@ char *packet_read_line_buf(char **src_buf, size_t
>>> *src_len, int *size);
>>> */
>>> ssize_t read_packetized_to_strbuf(int fd_in, struct strbuf *sb_out);
>>>
>>> +struct packet_reader {
>>> + /* source file descriptor */
>>> + int fd;
>>> +
>>> + /* source buffer and its size */
>>> + char *src_buffer;
>>> + size_t src_len;
>>
>> Can or should this be a strbuf?
>>
>>> +
>>> + /* buffer that pkt-lines are read into and its size */
>>> + char *buffer;
>>> + unsigned buffer_size;
>>
>> Likewise.
>
> This struct is setup to be a drop in replacement for the existing
> read_packet() family of functions. Because of this I tried to make the
> interface as similar as possible to make it easy to convert to using it
> as well as having no need to clean anything up (because the struct is
> really just a wrapper and doesn't own anything).
Sorry, I don't completely follow. Are you saying some callers play
with the buffer, or are you saying you haven't checked? (If the
latter, that's perfectly fine; I'm just trying to understand the API.)
Either way, can you add some comments about ownership / who is allowed
to write to it / etc to make it easier to clean up later?
Thanks,
Jonathan
