This is the mail archive of the 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: Tim Hollebeek <>
   This thread is about shutting up warnings, when p is *known* to be a
   pointer for which [a cast to integer] is safe.

   By your rule, all cast from a (potentially) wider type to a smaller
   type deserve a warning.  By that rule, this warning, and hundreds of
   other false positives like it, are unavoidable.  Practical experience,
   however, shows that most pointer abuse comes from cases between
   pointers and smaller sized integral types.


Here's the rule I suggest for warnings about conversions between
values of unequal width that I think makes sense for -Wall:

	When a default conversion is implied by the code and that
	conversion is potentially lossy (on any architecture),
	generate a warning.

An explicit cast is not a default conversion and should not generate a

Perhaps rth is right when he says that people often use explicit casts
incorrectly.  So it would also be nice to have "-Wcommon-mistakes"
that would generate warnings about possibly lossy explicit casts.
"-Wall" should not do so, in order to preserve the useful and historic
meaning of "-Wall" in GCC.  If you don't want to use the name "all"
for that traditional meaning, I wouldn't have any objection to renaming
it "-Wclean" or some such.

My suggested rule for printing warnings about default conversions will
generate more warnings than GCC traditionally did.  Traditionally, the
warnings seem to have been architecture specific.  I think the rule
was something like:

	When a default conversion is implied by the code and
	that conversion is potentially lossy (on the target
	architecture), generate a warning.

Possibly that warning only applied between pointers and integers, I'm
not sure off the top of my head.  (So maybe -Wcommon-mistakes,
-Wcommon-mistakes-target, -Wall/clean and -Wall/clean-target.)

   The ptr <--> int boundary is far more likely to indicate an
   unwarranted assumption than the conversion between integral types of
   different sizes, and the valid conversions between integral types of
   different sizes occur far too often in reasonable code to generate

"far more likely"?  You've done a study of this?  What source did you
examine and where can I see the methodology and results?  Even if
that's the case, "-Wall" used to have a fairly specific and useful
meaning and the property that you could pass all "-Wall" checks in a
portable way without having to break your code.

My rules are based on the observation that the standards assure us
that some conversions are unsafe from the compiler's perspective.  The
language definition includes a cast operator which implies no change
in the code generated, but which can be used to mark those unsafe
conversions explicitly.  I can't see any use for those cast operators
if not to shut up compiler warnings: to say "Yes, I am using this 
potentially dangerous operation knowingly."

   Let's face it, *any* conversion between pointers and integers
   *already* invoked implementation defined behavior.  

Which is neither entirely true nor particularly relevent.

   Please be familiar with this material before quoting basic references
   at me.

I am.  I pointed out the materials to establish a common frame of
reference since you seemed to think that `intptr_t' was a reasonable


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