|
From: Julian S. <js...@ac...> - 2005-02-25 14:20:31
|
> Any thoughts about this? The "char != signed char" idea seems crazy, but
> maybe it is worth cleaning up our intermixing of signed and unsigned types
> a bit? Or perhaps we could use -no-pedantic-signed-warnings, or whatever
> the option is, if there is one? Once GCC 4.0.0 is released, we'll have to
> deal with this, because I'm sure people will freak out at the huge numbers
> of warnings we get with it.
I'm already on the case. Basically the Intel compiler (icc 8) will tell
you all about this, and much, much more.
pub/libvex_basictypes.h says:
typedef unsigned char UChar;
typedef signed char Char;
typedef char HChar; /* signfulness depends on host */
/* Only to be used for printf etc
format strings */
and I intend to push those types through the entire code base so
it compiles cleanly with icc (vex is already largely done).
I guess that would keep gcc4 quiet too. I have to say I think
the more aggressive typechecking from gcc4/icc can only be a good
thing in the end; we should fix our code rather than add
flags to silence warnings.
HChar is what you need for literal strings, and has unknown
signfulness (whatever the host has).
Placating icc when it is in ultra-paranoid mode (-Wall, which is
far more paranoid than gcc's interpretation of same) is a bit
of a drag, but just occasionally it comes up with something
which could save hours of bug-hunting in the future, like this:
priv/guest-x86/toIR.c(323): remark #810: conversion from "int" to
"UShort={unsigned short}" may lose significant bits
vge->len[vge->n_used-1] += size;
(size is Int, len[] is UShort[]). Icc is quite correct here in
that some external guarantee has to be provided that len[] values
will not overflow. gcc (3.X, at least) makes no comment.
I didn't know that gcc4 is more picky than gcc3. That's a good
thing.
J
|