From: Perry E. Metzger <perry@pi...> - 2004-03-30 03:53:16
gcc with -Wall warns about integers that would be treated as negative
by traditional preprocessors but which are not treated as such today,
EXCEPT if those ints are expressed in hex.
genesis creates a bunch of such integers in constants.h, such as the
ones for DYNAMIC_SPACE_START and DYNAMIC_SPACE_END, carefully
putting them in the file as decimal with the hex in comments.
Could we reverse that and put the hex in actively and the decimal in
comments? That would suppress a bunch of spurious warnings.
BTW, I've found a bunch of very nasty bugs so far in my gcc warnings
examination, most of which would probably cause serious trouble on 64
bit architectures, so I think it has been worth it. I'm going to send
another round of patches shortly.
Perry E. Metzger perry@...
From: Perry E. Metzger <perry@pi...> - 2004-03-30 14:46:55
Christophe Rhodes <csr21@...> writes:
> "Perry E. Metzger" <perry@...> writes:
>> gcc with -Wall warns about integers that would be treated as negative
>> by traditional preprocessors but which are not treated as such today,
>> EXCEPT if those ints are expressed in hex.
> Does this mean that traditional preprocessors (which I thought only
> dealt with tokens, not with their semantics -- but I'm willing to
> accept education on this)
I misspoke in mentioning the preprocesor. Here is what the gcc man page
says, in describing -Wtraditional:
The ISO type of an integer constant has a different width or
signedness from its traditional type. This warning is only
issued if the base of the constant is ten. I.e. hexadecimal or
octal values, which typically represent bit patterns, are not
We could also shut up -Wtraditional but I'm not sure that is the right
Perhaps shutting it up and flagging constants larger than 2^31 with U
might be better -- I'm not sure.
> when confronted with one of these large
> numbers in hex would do the right thing, or that the traditional
> preprocessors would do the wrong thing but this is the only way of
> shutting modern gcc up?
It is just a way of shutting up gcc.
>> Could we reverse that and put the hex in actively and the decimal in
>> comments? That would suppress a bunch of spurious warnings.
> See attached. But if the warnings are really spurious, wouldn't it be
> better to fix gcc?
Well, turning off -Wtraditional might miss other errors that are
real. Semantics have changed in recent years in gcc, and I think it is
useful to flag things that might have different semantics on different
compilers, even going forward, because people sometimes use
constructs expecting the old semantics if they are used to them.
On the other hand, it also flags perfectly legitimate constructs, so
maybe we should just shut it up. I'm not sure.
>> BTW, I've found a bunch of very nasty bugs so far in my gcc warnings
>> examination, most of which would probably cause serious trouble on 64
>> bit architectures, so I think it has been worth it. I'm going to send
>> another round of patches shortly.
> Be quite careful... there are bound to be 32/64-bit confusions in the
> system, but they might not be in quite the way you think. SBCL
> already runs on a 64-bit architecture (the Alpha), but it does so in a
> very 32-bit way; a lispobj is a 32-bit quantity.
I know, but I assume that someday someone will want to fix that, and
fixing the LP 64 vs I 32 issues is probably good...
> (There also exists a
> branch of the CVS with a more natural 64-bit lispobj on the alpha,
> but, alas, it doesn't quite work yet -- quite possibly at least partly
> because of hideous 32/64 issues that you've observed :-).
Perry E. Metzger perry@...