Date: Thu, 5 Jul 2001 22:22:11 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: chgrp broken on alpha systems Message-ID: <Pine.BSF.4.21.0107052211560.37078-100000@beppo> In-Reply-To: <20010706150804.B506@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Jul 2001, Peter Jeremy wrote:
> On 2001-Jul-05 20:31:43 -0700, Matthew Jacob <mjacob@feral.com> wrote:
> >Perhaps what we really need- and this is really a toolchain issues- is a
> >compiler that is just as stringent on i386 as on alpha?
>
> IMHO, the compiler _is_ just as stringent on i386 as Alpha (it's the
> same compiler).
True. I didn't quite put it correctly. It's true that the compilers are
the same- but they do have different code generators, and they really do
have different levels of acceptance for errors that don't seem to be
type related.
> 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.
> Secondly, there are cases where different architectures
> map foo_t onto different primitive types. Both these problems are
> very difficult to solve using a lint-like tool running on only one
> architecture.
>
> As examples of the latter, a quick diff of
> /sys/{i386,alpha}/include/{ansi,types}.h reveals the following:
> i386 type Alpha type
> clock_t unsigned long int
Both should be u_int32_t until we decide Unix will last past 2038(?) in
which case they'll both be uint64...
> ptrdiff_t int long
> size_t unsigned int unsigned long
> ssize_t int long
> off_t __int64_t long
> *physaddr { int r[1]; } { long r[1]; }
> label_t { int [6]; } { long [10]; }
> vm_offset_t unsigned int unsigned long
> vm_ooffset_t __int64_t long
> vm_pindex_t unsigned int unsigned long
> vm_size_t unsigned int unsigned long
> register_t __int32_t __int64_t
> u_register_t __uint32_t __uint64_t
> intfptr_t int long
> uintfptr_t unsigned int unsigned long
I'm a little out of my depth about the right thing here- my
heavy toolchain experience is >= 10 years ago. I wish Bruce and/or David
could help sort this out.
-matt
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?Pine.BSF.4.21.0107052211560.37078-100000>