This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pointer <-> integer conversion warnings (bogus -Wall warnings)




   From: Richard Henderson <rth@redhat.com>
   On Wed, Mar 13, 2002 at 04:25:51PM -0800, Tom Lord wrote:
   >	x = (int)(size_t) p;
   > 
   > That double cast is not safe.

   Care to explain your reasoning?  

I'm sure we can all figure it out.

   Care to point to a system for which it fails?

The one released in 2008 that has 64 bit pointers and integers with 32
bit size_t.


   > The simple rule that explicit casts to appropriate types don't
   > generate warnings in the absense of extraordinary options gives this
   > class of warnings a clear and useful relation to the various
   > standards.  I don't understand why that rule is at all controversial.

   Because virtually all code that pointer to integer casts with "int" 
   breaks on 64-bit targets.  This is not speculation; this is hard
   experience bringing alpha-linux up from the first shell prompt.

   The warning isn't going to change.  It is going to remain enabled
   with no -W flags whatsoever.  Live with it.

To match your tone I guess I'd have to make fun of you for confusing
"virtually all code" with "alpha-linux" and express my shock that a C
compiler maintainer would have such a sloppy attitude.  I really
didn't want this to be a stupid mutual insult war, though.  Really.  I
had this foolish idea that the GCC maintainers might want to find ways
to balance the classical beauty and specificity of C with the
pragmatic needs of the poor sods that have to do things like port
Linux to alpha.

It would be perfectly reasonable, as I've said repeatedly, to have an
option that generates the warnings you want.  It would be reasonable
to encourage Linux and Linux app developers to use that option
regularly.  It would be reasonable to work on the problem at the right
level: by improving the kind of testing infrastructure that exists for
Linux and Linux app developers.  

On the other hand, heck, _why_not_ just make GCC less of a real C
compiler in _just_one_more_ way.  Who cares?  What difference does it
make, _really_?  Especially if it means _rth_wins_!

-t


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]