Date: Sun, 29 Aug 2010 13:04:16 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: Alexander Best <arundel@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: hexdump(1)/od(1) skip function off-by-one when offset == file length Message-ID: <AANLkTinmAom3j-jm3psKXfGY-fc5XXBaqEdU6Go7GTPe@mail.gmail.com> In-Reply-To: <20100829162707.GA98059@freebsd.org> References: <20100829162707.GA98059@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 29, 2010 at 9:27 AM, Alexander Best <arundel@freebsd.org> wrote:
> just discovered this issue while going through some linux mailinglists:
>
> otaku% dd if=/dev/urandom of=testfile bs=1 count=42
> 42+0 records in
> 42+0 records out
> 42 bytes transferred in 0.000393 secs (106894 bytes/sec)
>
> otaku% hexdump -s 42 testfile
> 000002a 134d b7b9 e085 da16 63b0 554a 1603 ead0
> 000003a 4bd1 fbfd c329 b606 e592 1377 6e10 4b9d
> 000004a c018 0fc9 ebf4 9ae2 9f1a
> 0000054
>
> otaku% hexdump -s 43 testfile
> 000002a
>
> otaku% hexdump -s 41 testfile
> 0000029 009f
> 000002a
>
> the attached patch fixes this issue for HEAD. i also checked out any license
> issues which could pop up. this fix comes from the util-linux-ng repository [1]
> which seems entirely GPLv2'ed. :)
Lest they forget that they code was originally BSD licensed, not
GPLv2 (except for new source I suppose)...
According to the manpage...
-s offset
Skip offset bytes from the beginning of the input. By default,
offset is interpreted as a decimal number. With a leading 0x or
0X, offset is interpreted as a hexadecimal number, otherwise,
with a leading 0, offset is interpreted as an octal number.
Appending the character b, k, or m to offset causes it to be
interpreted as a multiple of 512, 1024, or 1048576, respectively.
... I would expect the following output:
1. -s 41 -> one byte displayed.
2. -s 42 -> no bytes displayed.
2. -s 43 -> no bytes displayed.
This is the case with your patch alone, but with the another patch
I posted (see bin/118723), it's completely broken, so there might be
an issue with the proposed change on either end. The logic in hexdump
is in serious need of fixing because there are tons of cornercases
like this in the code.
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinmAom3j-jm3psKXfGY-fc5XXBaqEdU6Go7GTPe>