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 round-up




       > lord:
       > A variety of double-cast workarounds have been suggested as
       > the means to suppress the warning.  None of these really
       > solves the problem:

       fjh:
       This comment suggests that you still don't understand the
       proposed double-cast work-around properly. 

	> 	type		sizeof(type)
	> 
	> 	short		2
	> 	int		8
	> 	long		8
	> 	intptr_t	8
	> 	void *		4

	I guess you must be assuming that the intermediate type used
	on such a system would be `short', not `intptr_t'.

I was assuming that there were two intermediate types: one for
pointer->int, one for int->pointer.  But suppose there is only one:
If it is intptr_t, then an int->pointer conversion will generate
the warning we're trying to get rid of.  If it is short, the warning
will be supressed, but the conversion incorrect.

The point is, the double-cast trick, even if with gigantic CPP
conditionals to pick the one or two intermediate integer types, is a
platform-specific solution that only works on some platforms.  It
doesn't actually make the code any more portable than the single cast
solution; it doesn't reliably prevent truncating conversions.  The
single cast expresses exactly the intended (platform specific) code
already; it should be possible to use that legal construct without
getting a warning.

	> fjh proposes that, if such systems ever become important,
	> gcc can treat double-casts as a special case (by not giving
	> warnings).

	Or just not issue these warnings at all on such systems.
	In other words, treat such systems as a special case
	(rather than treating double-casts as a special case).

That's really close to an option (on all platforms) which disables
warnings for conversions marked by explicit casts.  Such an option 
would satisfy me.

Here's another possible solution that seems more in keeping with
the general style of GCC (though I'd guess it's much more work than
just a warning control option): an expression:

	x = (int)__trunc__(p);
	p = (void *)__trunc__(x);

which supresses warnings, with the usual "#if !defined(__GNUC__)" to
define __trunc__ for other compilers.  Or even an expression that
let's me state the expected range of the integers, and gives
width-warnings for those when appropriate:

	x = (int)__trunc__(p, N_BITS);

Once again, I have this habit -- and I think there are many C
programmers with the same habit -- of using casts carefully and using
the warning (or error) system of the compiler to detect various kinds
of editting error.  You change the type of some variable; an
assignment or function parameter that was previously correct now
generates a warning or error; you think about what that assigment
means across the platforms you're interested in; either you change the
types of variables further or you decide the conversion is intended
and add the required cast.  Repeat that until all the warnings
disappear (and similarly fix dead code, dead variables, dead labels,
unclear flow of control, incorrect uses of printf format strings, and
all the other fine warnings GCC generates.  If you're an emacs user,
for example, when the first invocation of `M-x next-error' says only
"No more errors", you're in good shape by a useful metric.

This has a practical consequence.  Recently, a package that I
distribute failed to run on a 64 bit system.  There was a real bug: a
place in the code where a pointer to an integer of one size was passed
as if it were a pointer to an int of a different size.  In keeping
with my coding practices, this conversion was _not_ marked with a
cast.  When I finally saw that error, it stood out immediately because
of the lack of a cast.  At the same time, though, there were six other
places in the code where correct, non-buggy conversions were written
with a cast.  All of these generated warnings.  Two volunteer
contributors to the code saw these and took GCC's warnings at face
value.  They spent time trying "fix" that non-broken code, even to the
point of preparing and exchanging patch sets; running test suites;
etc.  Plenty of time was wasted and since I can easily imagine that
scenario being repeated, it's worth finding the right solution.


-t


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