Re: [PATCH v2 2/8] t0021/rot13-filter: refactor packet reading functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christian Couder <christian.couder@xxxxxxxxx> writes:

> +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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux