> 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.
0xAA, even in the single-byte character set ISO 8859/1, is a printable
character (it's "FEMININE ORDINAL INDICATOR", i.e. a superscript
underlined "a").
It may, however, have something to do with the fact that handing "char"
to "is<whatever>()" is a Bad Idea, thanks to the fact that C was
developed, during an era in which most character sets were 7 bits (at
least for Western European languages - ISO 8859/x didn't exist yet, and
I think there were only the national flavors of the ISO 646 character
sets, which, as I remember, have a set of character positions reserved
for national characters; ASCII was the US ISO 646 character set, which
put some symbols there, but in some other countries accented letters
were, I think, put there), on a machine whose byte-load instruction
sign-extended.
I.e., it's a consequence of the very unfortunate fact that "char" is
signed in most C implementations. If you have a character with the 8th
bit set, as a "char" value on most platforms it's negative, and the
"isXXX()" macros/routines don't properly handle negative values (other
than perhaps -1 a/k/a EOF).
If you do
isgraph(0xAA)
the 0xAA will be treated as an integral constant with the hex value (on
a 32-bit platform) 0x000000AA; however, if you do
char c = 0xAA;
isgraph(c);
on a platform with signed "char", the 0xAA will be converted to "char"
and assigned to "c", giving an 8-bit signed value 0xAA, which will be
treated as a negative value which, when converted to a 32-bit integral
value, will be 0xFFFFFFAA. If your simple app just passed 0xAA to
"isgraph()", that might explain why (it would also indicate that your
app is running with a locale that doesn't specify ISO 8859/1 as the
character set - it may be the "C" locale (ANSI C specifies that
At program startup, the equivalent of
setlocal(LC_ALL, "C");
is executed.
so that the default locale is the "C" locale, which is "the minimal
environment for C translation", in which the character set may be ASCII,
even on Windows, with code points that don't correspond to ASCII
characters not being considered graphic characters).
The correct answer would probably be to replace "gchar" with "guchar" in
"packet_hex_print()"; that means that the handling of characters with
the 8th bit set may then be platform-dependent, and dependent on the
character set the user has specified (e.g., by setting LANG or another
environment variable in UNIX), but that may be good enough.
