Re: [PATCH v2 2/8] t0021/rot13-filter: refactor packet reading functions
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 7, 2017, 01:15 UTC
- Message-ID
- <xmqqo9oehotn.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20171105213836.11717-3-chriscool@tuxfamily.org>
Christian Couder <christian.couder@gmail.com> writes:
Show 8 quoted lines
> +sub packet_required_key_val_read {
> + my ( $key ) = @_;
> + my ( $res, $buf ) = packet_txt_read();
> + unless ( $res == -1 or ( $buf =~ s/^$key=// and $buf ne '' ) ) {
> + die "bad $key: '$buf'";
> + }
> + return ( $res, $buf );
> +}The function calls itself "required", but it does not die when it sees an unexpected EOF or an empty line. Neither of these cases gives it a key (nor val), but it is not treated as an error.
That is curious, isn't it?
By the way, is it just me who finds this "unless" even less unerstandable than the original in packet_txt_read() you modeled this one after? The original depended on packet_bin_read() to die on an unexpected EOF, so its "unless" made some sense (we know we got some input, and it is an error for the input not to end with LF unless it is an empty string). Negating the condition and making it "if" may make it easier to understand, perhaps. I dunno.