On Sun Aug 29 10, Garrett Cooper wrote: > On Sun, Aug 29, 2010 at 9:27 AM, Alexander Best <arun...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
