Date: Mon, 30 Aug 2010 10:38:59 +0000 From: Alexander Best <arundel@freebsd.org> To: Garrett Cooper <gcooper@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: hexdump(1)/od(1) skip function off-by-one when offset == file length Message-ID: <20100830103859.GA27716@freebsd.org> In-Reply-To: <AANLkTinmAom3j-jm3psKXfGY-fc5XXBaqEdU6Go7GTPe@mail.gmail.com> References: <20100829162707.GA98059@freebsd.org> <AANLkTinmAom3j-jm3psKXfGY-fc5XXBaqEdU6Go7GTPe@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun Aug 29 10, Garrett Cooper wrote: > 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)... *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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100830103859.GA27716>