In said:
The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.
If you think that the amount of existing broken code can prove anything,
you're sorely mistaken. The days when all the world was a 32-bit
platform are gone...
The warnings can become a nuisance and people would stop
using this feature. Personally I think warnings should be
kept to the essential ones, warnings that would uncover a
possible error.
In your stupidity, you don't realise that this is a genuine error, it
just doesn't manifest on *your* platform. Try to engage your brain
and think about platforms with 32-bit int's and 64-bit pointers
(increasingly common since DEC released Alpha OSF/1 in 1992).
To show you that the issue is *real* and not invented ad-hoc:
lx64:~/tmp 11> uname -m
x86_64
lx64:~/tmp 12> cat test.c
#include <stdio.h>
int main(void)
{
int i;
printf("%#x %p\n", &i, (void *)&i);
return 0;
}
lx64:~/tmp 13> gcc test.c
lx64:~/tmp 14> ./a.out
0xbffff00c 0x7fbffff00c
lx64:~/tmp 15> gcc -Wall test.c
test.c: In function `main':
test.c:6: warning: unsigned int format, pointer arg (arg 2)
As you can see, the two values are different: %x has lost information.
So, the people developing their code on your compiler will have a bad
surprise when trying to use it elsewhere and you believe that you're
doing them a favour!
Strictly speaking you should use %p, but I have almost
never seen it in debugging code, where this conversion is
used.
To the contrary of your expectations, I work to make a usable
compiler, not one that will please the purists around c.l.c
If you think you're doing your users any service by not diagnosing
their genuine mistakes, simply because they *accidentally* work on
your platform, you're even more stupid than I thought. People like you
have no business messing with compilers and libraries.
The FAQ *should* contain the following question: "Why should I avoid
lcc-win32 like the plague?". But the answer would significantly increase
its current size...
Dan