[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#8064: hexdump not big-endian aware



On Fri, 14 Mar 1997, Eric Delaunay wrote:

> Package: bsdmainutils
> Version: 3.2-0
> 
> I just found one bug in hexdump after I compiled it for Debian/SPARC:
> it doesn't handle multi-bytes output because it is based on cast that only
> works for a little-endian architecture IMHO.
> 
> For instance, in display.c(line 194):
>                 case 2:
>                         bcopy(bp, &u2, sizeof(u2));
>                         (void)printf(pr->fmt, (u_quad_t)u2);
>                         break;
> 
> u2 is of u_int_16 type. Then casting it to a u_quad_t but viewing it using a
> "%04x" display format shows the wrong bytes (upper ones instead of lower ones)
> on big-endian architectures.
> Sorry, I don't have time to spend on it :-((
> Anybody have an idea to fix it? It should be done for all type displayed, I
> guess.
> 
> Regards.
> 
> PS: I cc: this mail to debian-sparc if there is any volunteer who would work
>     on it.

On Tue, 13 May 1997, Patrik Rak wrote:

> Package: bsdmainutils
> Version: 3.2-0
> 
> m68k version of hexdump does not work properly. It seems to have problems
> printing hexadecimal numbers, since both the offsets and the values which
> are printed always come out as zeroes.
> 
> Just for the record, I use kernel 2.0.29.
> 
> Script started on Mon May 12 09:53:24 1997
> $ echo "abcd" >test
> $ cat test
> abcd
> $ hexdump test
> 0000000 0000 0000 0000
> 0000000
> $ hexdump -c test
> 0000000   a   b   c   d  \n
> 0000000
> $ exit
> 
> Script done on Mon May 12 09:54:36 1997

On Tue, 20 May 1997, Patrik Rak wrote:

> On Tue, 13 May 1997, Austin Donnelly wrote:
> 
> > > Package: bsdmainutils
> > > Version: 3.2-0
> 
> > > $ hexdump test
> > > 0000000 0000 0000 0000
> > > 0000000
> > > $ hexdump -c test
> > > 0000000   a   b   c   d  \n
> > > 0000000
> > > $ exit
> > > 
> > 
> > This looks like it could be related to the endian problems hexdump
> > has.
> 
> Might be, but I don't think so bcs also the offsets printed are always
> zero (unless the the bytes are swapped in the printing routine instead
> when fetched from the file - in that case it could be the endian problem
> which should be quite easily found then) 

I've applied a patch from Eric Delaunay which removes some casts of
data to 32bit wide types: hopefully this should solve the problems.

I am unable to test this on a big endian machine, since I don't have
any, so this may not actually correct the problem.  Little endian
machines should be unaffected.

I'm closing these bug report, but if there are still problems, feel
free to submit more bug report.

Thanks,
Austin


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-sparc-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: