Re: [Qemu-devel] [PATCH for-4.2 12/13] iotests: Add peek_file* functions

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2121 bytes --]

On 30.07.19 21:22, Eric Blake wrote:
> On 7/30/19 12:25 PM, Max Reitz wrote:
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>>  tests/qemu-iotests/common.rc | 20 ++++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
>> index 5502c3da2f..78decfd5d5 100644
>> --- a/tests/qemu-iotests/common.rc
>> +++ b/tests/qemu-iotests/common.rc
>> @@ -53,6 +53,26 @@ poke_file()
>>      printf "$3" | dd "of=$1" bs=1 "seek=$2" conv=notrunc &>/dev/null
>>  }
>>  
>> +# peek_file_le 'test.img' 512 2 => 65534
>> +peek_file_le()
>> +{
>> +    # Wrap in echo $() to strip spaces
>> +    echo $(od -j"$2" -N"$3" --endian=little -An -vtu"$3" "$1")
> 
> Requires coreutils' od, but we can patch that later if it proves to be a
> problem on other hosts.
> 
> I used to do something similar in nbdkit (prior to qemu-nbd --list
> making my life a lot easier; see nbdkit commit b228cb40); but there, I
> read a 16-bit value in 2 8-bit chunks and pieced it together myself
> rather than relying on --endian:
> 
> -    # Protocol is big endian, we want native endian.
> -    # xargs trick to trim whitespace from
> -    # https://stackoverflow.com/a/12973694
> -    eflags_hi=$(od -An -N1     -tx1 eflags.out | xargs)
> -    eflags_lo=$(od -An -N1 -j1 -tx1 eflags.out | xargs)
> -    eflags=$(( 0x$eflags_hi << 8 | 0x$eflags_lo ))
> 
> But as long as we are using --endian, your version nicely handles 1, 2,
> 4, and 8-byte reads.
> 
>> +
>> +# peek_file_raw 'test.img' 512 2 => '\xff\xfe'
>> +peek_file_raw()
>> +{
>> +    dd if="$1" bs=1 skip="$2" count="$3" status=none
>> +}
> 
> Of course, calling $(peek_file_raw ...) is a bad idea, because it might
> eat a trailing byte that happened to be a newline; it also doesn't
> handle NUL bytes very well.  Is it worth documenting caveats for using
> this one?

In my experience, it handled NUL bytes so well that I had to tr -d them
away. :-)

I mean, isn’t the problem in the caller, then?

Max

> Reviewed-by: Eric Blake <eblake@redhat.com>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]