hexdump(1)/od(1) skip function off-by-one when offset == file
arundel at freebsd.org
Mon Aug 30 10:38:59 UTC 2010
On Sun Aug 29 10, Garrett Cooper wrote:
> On Sun, Aug 29, 2010 at 9:27 AM, Alexander Best <arundel at 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 
> > which seems entirely GPLv2'ed. :)
> Lest they forget that they code was originally BSD licensed, not
> GPLv2 (except for new source I suppose)...
*hehehe* that might be true. maybe they've bought the src from AT&T? anyway i
don't think the BSD license restricts you releasing code under a new license.
so what they did seems fine to me.
> 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.
i saw that you're working on fixing some hexdump bugs. after looking at the
code i decided that this fix will be my only contribution. the code is a huge
mess and way too complicated. i've started to rewrite the code (pretty much
from scratch). not only is the code ugly it's slow and inefficient. just one
hexdump asumes that if a file isn't regular this means it's non-seekable.
that's just plain wrong. it took me half an hour to hack in a few changes to
make hexdump skip over a couple of hundred megabytes of my harddrive's device
node withoutout any delays. using the current versin of hexdump for that took
about 10 minutes!!!
the point is that i don't think fixing hexdump is worth anyone's time, because
it really needs to be rewritten from scratch.
More information about the freebsd-hackers