From owner-cvs-all Thu May 7 07:48:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24406 for cvs-all-outgoing; Thu, 7 May 1998 07:48:50 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA24394 for ; Thu, 7 May 1998 07:48:42 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id FAA08739; Thu, 7 May 1998 05:46:21 -0400 (EDT) From: Peter Dufault Message-Id: <199805070946.FAA08739@hda.hda.com> Subject: Re: cvs commit: src/sys/sys termios.h In-Reply-To: <199805062234.PAA00632@antipodes.cdrom.com> from Mike Smith at "May 6, 98 03:34:51 pm" To: mike@smith.net.au (Mike Smith) Date: Thu, 7 May 1998 05:46:21 -0400 (EDT) Cc: jb@cimlogic.com.au, committers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > To get a working FreeBSD/Alpha using a NetBSD kernel, I want to make as > > few changes to FreeBSD sources as possible, and avoid destabilizing i386 > > in the process. On alpha, that means int is 32 bits, long is 64 bits. > > Where there are variables in user-space that are passed to the kernel in > > FreeBSD/NetBSD and the size of these variables differs when compiled on > > alpha, I change the variable so that there is no effective change to i386. > > This commonly means that things coded as long and used as 32-bit integers > > are changed to int. And pointers that are cast to int are changed to cast > > to long. > > Is there a serious impediment to using *int32_t/*int64_t instead? > These give you explicitly-sized storage, and make it clear that you > mean them to stay that way... (I'm actually USING termios.h in a 16 bit environment right now, but it is a moot point since I'll never upgrade the one I'm using.) Changing to "naked int" to mean "signed 32 bit" is backwards. It is discarding information. In system headers where the language doesn't require int behavior, I agree that using typedefs for the two cases you describe is in order. Expecting int to be >= 32 bits for new stuff is fine. If there aren't many typedefs to change I'd make up descriptive typedefs. If there are lots or I don't want to trouble my brain, I'd not worry, be happy, and use int32_t. Peter "1s and 0s?!? We had to use only letter Os!" Dufault -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message