This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pointer <-> integer conversion warnings (bogus -Wall warnings )
On 14-Mar-2002, Tom Lord <lord@emf.net> wrote:
>
> For the double-cast trick, we need two integer types:
>
> small_int_t: a type large enough to hold our limited range
> integers, but not wider than pointers.
>
> large_int_t: an integer type large enough to hold pointers
>
> On all the current, popular architectures, using posix *_MAX macros,
> we could undoubtedly find such types. However, the standards give us
> no assurance of being able to find such types and it isn't hard to
> imagine quite plausible systems on which they don't both exist.
large_int_t doesn't need to be large enough to hold pointers. For the
double-cast code to work (i.e. to behave the same as the single cast),
large_int_t just needs to be at least as big as small_int_t.
This is easy to achieve.
For the double-cast to suppress the warning, large_int_t needs to be
exactly the same size as a pointer. This is not necessarily so easy
to achieve. However, if there is no standard integer type which is the
same size as a pointer, then a "reasonable" compiler should not issue the
warning about casts from pointer to integer of different size. Hence the
double-cast hack will suppress the warning on all architectures, for all
"reasonable" compilers.
Currently AFAIK GCC has not been ported to any platform for which `size_t'
is not the same size as pointers. So all current ports of GCC are
"reasonable" in this sense.
> Consequently, the double-cast trick is a platform-specific hack -- not
> a feature of C.
It's a somewhat-compiler-specific hack, to supress a particular compiler
warning. It is not at all platform-specific. The same hack works with
any "reasonable" compiler on any platform, including GCC on all the
platforms that GCC has currently been ported to.
If you worried about GCC issuing spurious warnings on platforms for which
it has not yet been ported to, well, feel free to file a PR, but this is
not what I would consider a high-priority problem... it can easily be fixed
by modifying GCC to not issue the warning if there is no pointer-sized
standard integer type, but there's no need to fix it right away.
> > Three levels of
> > meaning for "this is clean code" are:
> >
> > a. it compiles
> > b. it compiles with all the usual warnings
> > enabled, without generating any warnings
> > c. it passes inspection by <your favorite lint tools>
> >
> > Now, with the
> > pointer<->integer conversion warnings enabled by default and by
> > '-Wall', level (b) is gone.
>
> If you think `-Wall' is supposed to mean your level (b), then I think
> your are wrong. The documentation for -Wall says [...]
>
> Regardless of the documentation, until fairly recently, `-Wall'
> provided (b). I've already said that providing an option that gives
> the traditional warnings but isn't called `-Wall' would be fine.
Well, I would not be opposed to such an option.
If you really want it, I suggest you go ahead and post a patch for it.
> (I'd prefer `-Wall', but that's a minor point.)
I doubt this would gain concensus.
> At least as of the version of GCC I use, warning about default
> conversions between possibly incompatible sizes only generate warnings
> on platforms where those conversions are _actually_ incompatible
> sizes. That blows. An improvement would be to give warnings, even in
> the default case, when a default conversion can be between
> incompatible sizes on _any_ architecture. This would even be likely
> to catch at least a few bugs before they bite the person doing an
> alpha port.
I completely agree.
However, this would be very difficult to implement without
introducing lots of spurious false positives.
You want `(int) p' to result in a warning, whereas `(intptr_t) p' should not.
But `intptr_t' may be just a typedef for `int'.
And `(int) p' should not result in a warning if it is the
result of macro-expanding `(my_intptr_t) p', where my_intptr_t
is a macro whose definition was generated by autoconf.
The compiler can't easily tell if that is the case.
> An explicit cast, though, expresses the programmer's intention to
> invoke a potentially dangerous conversion. Except in the presence of
> an option like `-Wcommon-mistakes' or `-Wcheck-for-possible-idiocy',
> no warning should be generated.
`-Wall' *is* such an option, IMHO.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.