> >On i386, 'gcc -fsyntax-only -Wall x.c' produces no error. On
> >NetBSD/alpha (same compiler, really), this produces:
> >
> >x.c: In function `func':
> >x.c:4: warning: cast from pointer to integer of different size
> >
> >It'd be *really* nice if we could add a flag where such errors could be
> >checked for and emitted for an i386 build.
>
> David would know for certain, but I think this is messy to detect. As
> I see it, the problem is that when casting a pointer type to an
> integer type, gcc only looks at the lengths of the types - on an i386,
> sizeof(int) == sizeof(long) == sizeof(void *), whereas on an Alpha,
> sizeof(int) != sizeof(long) == sizeof(void *). Whilst it is possible
> to change the check so that it verifies that the integer type is
> `long' (or longer), this may cause other problems.
Yes. Fooling around with compilers is like fooling around with a partially
loaded revolver.
I was browsing through c-typeck.c, and I don't see a really good way of doing
this other than:
if (TREE_CODE (type) == INTEGER_TYPE
&& TREE_CODE (otype) == POINTER_TYPE
&& TYPE_PRECISION (type) != TYPE_PRECISION (otype)
&& !TREE_CONSTANT (value))
warning ("cast from pointer to integer of different size");
+ if (warn_other_precision_width && TREE_CODE (type) == INTEGER_TYPE
+ && TREE_CODE (otype) == POINTER_TYPE
+ && warn_other_precision_width != TYPE_PRECISION (otype)
+ && !TREE_CONSTANT (value))
+ warning ("pointer to integer cast would break on %d bit pointers",
+ warn_other_precision_width)
where warn_other_precision_width is set with -Wptrsize=N, where N is the width
in bits of a pointer type you want to compare it to.
>
> A further obstacle is that [u]intptr_t maps to an [u]int on the i386
> and I don't think that gcc can tell the difference between (int) and
> (intptr_t) when applied to a pointer.
Sigh, yes.
>
> One solution would be to make [u]intptr_t a `magic' type in gcc and
> have it whinge whenever a pointer or [u]intptr_t was cast or assigned
> to anything other than a pointer or [u]intptr_t. This is probably a
> non-trivial task in gcc and would lead to lots of false positives.
Yes.
>
> Overall, I think that making developers more aware of cross-platform
> issues,
That may or may not ever happen.
> combined with the availability of test boxes (like beast) is
> a better solution. It's definitely unreasonable to expect all
> developers to own machines for all the target architectures.
Why not? H/W's cheap enough :-)...
>
> Another random thought: If it was easier to build/install a
> cross-platform version of gcc, it might be easier to convince
> developers to at least check that compiling on different platforms
> works before committing.
>
All of these things are good ideas. There will still be breakage because
people will check things in with a "Oh- that's so simple, it won't break a
thing, and anyway, it compiled on my machine...". That's just such a hard
habit to break for the onesey-twosey types of changes.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
