From owner-freebsd-current Thu Jul 5 22:22:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 5B10037B407 for ; Thu, 5 Jul 2001 22:22:25 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (mjacob@beppo [192.67.166.79]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f665MBS37882; Thu, 5 Jul 2001 22:22:15 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 5 Jul 2001 22:22:11 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Peter Jeremy Cc: freebsd-current@FreeBSD.ORG Subject: Re: chgrp broken on alpha systems In-Reply-To: <20010706150804.B506@gsmx07.alcatel.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Jul 2001, Peter Jeremy wrote: > On 2001-Jul-05 20:31:43 -0700, Matthew Jacob 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