hexdump(1)/od(1) skip function off-by-one when offset == file length

[Alexander Best]

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 [1]
> > 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
random example:

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.

cheers.
alex

> Thanks,
> -Garrett

-- 
a13x