Date: Fri, 06 Jul 2001 16:37:43 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: chgrp broken on alpha systems Message-ID: <20010706163743.D506@gsmx07.alcatel.com.au> In-Reply-To: <Pine.BSF.4.21.0107052211560.37078-100000@beppo>; from mjacob@feral.com on Thu, Jul 05, 2001 at 10:22:11PM -0700 References: <20010706150804.B506@gsmx07.alcatel.com.au> <Pine.BSF.4.21.0107052211560.37078-100000@beppo>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Jul-05 22:22:11 -0700, Matthew Jacob <mjacob@feral.com> 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:
>
>x.c:
>
>int
>func(char *p)
>{
> 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.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010706163743.D506>