isgraph() is also responsible for the corrupted hex pane on the latest gtk
snapshot. In the case I'm looking at isgraph() says 0xAA is OK so it's
added to the buffer and gtk blows up trying to convert the buffer to the
internal gtk representation and ignores the whole line. As the line has the
linefeed in this is lost as well so the next line of output follows the
last.
A simple app doesn't show this behaviour as isgraph() returns false for
0xAA. I think that it's something to do with multi-byte character sets.
I'm going to have a look at it tonight so may have some answers tomorrow.
Regards,
Graham Bloice
Software Developer
Trihedral UK Limited
Tel: +44 (0)7002 874433
Fax: +44 (0)7002 228880
Email: mailto:graham.bloice@xxxxxxxxxxxxx
Web: http://www.trihedral.com
-----Original Message-----
From: owner-ethereal-dev@xxxxxxxx [mailto:owner-ethereal-dev@xxxxxxxx]On
Behalf Of Gilbert Ramirez
Sent: 27 April 2000 18:04
To: Dan Warburton
Cc: ethereal, dev
Subject: Re: [ethereal-dev] Hex dump problem?
On Thu, Apr 27, 2000 at 11:42:46AM -0500, Dan Warburton wrote:
>
>
> I used ethereal to debug a smtp exchange we have here. It looks
> like the Hex dump in the bottom pane does not always display spaces
> correctly... here is the exchange from the follow tcp stream...
Good catch. We use the isgraph() function to test whether a
character has a printable representation, and isgraph() says that
blanks do not have a printable representation.
isspace() returns true on *all* whitespace, which besides the space
character, includes tabs and vertical tabs.
So, I decided just to check for the ' ' character as well as
the return value of isgraph(). Attached is a diff to gtk/proto_draw.c
I'll be checking the change in.
Thanks!
--gilbert
