Hi,

Brandon Williams wrote:

> Add an 'unpack-sideband' subcommand to the test-pkt-line helper to
> enable unpacking packet line data sent multiplexed using a sideband.
>
> Signed-off-by: Brandon Williams <bmw...@google.com>
> ---
>  t/helper/test-pkt-line.c | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)

Neat.  It appears that this writes sideband channel 1 (packfile data)
to stdout, sideband channel 2 (progress) to stderr, and sideband
channel 3 (errors) cause the helper to fail.  It would have been nice
if a comment or the commit message said that, but it's no reason to
reroll --- the code is clear enough.

> --- a/t/helper/test-pkt-line.c
> +++ b/t/helper/test-pkt-line.c
> @@ -1,3 +1,4 @@
> +#include "cache.h"
>  #include "pkt-line.h"

I think this is for write_or_die.  Makes sense (well, in the same way
as any of the other functions that ended up in cache.h instead of a
more thought-through place do).

The old #includes were problematic, since the caller cannot count on
git-compat-util.h to be the first include of pkt-line.h.  See
Documentation/CodingGuidelines "The first #include" for more on this
subject.

[...]
> +static void unpack_sideband(void)
> +{
> +     struct packet_reader reader;
> +     packet_reader_init(&reader, 0, NULL, 0,
> +                        PACKET_READ_GENTLE_ON_EOF |
> +                        PACKET_READ_CHOMP_NEWLINE);
> +
> +     while (packet_reader_read(&reader) != PACKET_READ_EOF) {
> +             int band;
> +             int fd;
> +
> +             switch (reader.status) {
> +             case PACKET_READ_EOF:
> +                     break;
> +             case PACKET_READ_NORMAL:
> +                     band = reader.line[0] & 0xff;

reader.line[0] is a char. This promotes it to an 'int' and then ANDs
against 0xff, which would ensure it is a positive value.  In other
words, this does the same thing as

        band = (int) (unsigned char) reader.line[0];

but more concisely.

More importantly, it matches what recv_sideband does.  Good.

Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Thanks.

Reply via email to