On 2001-Jul-05 22:22:11 -0700, Matthew Jacob <[EMAIL PROTECTED]> wrote:
>> IMHO, the problem splits into two categories:
>> Firstly, sizeof(long) (and sizeof(void *)) differ between the Alpha
>> and the i386.
>Yes. This tends to be caught by the alpha compiler but the i386.
>It'd be nice if there were a -Wpun. For example:
> int j = (int) p;
> return j + 1;
>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.
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.
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, 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.
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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message