> >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.


> 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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to