From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3) with ESMTP id XAA19593 for ; Mon, 27 May 1996 23:25:16 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id JAA25944; Mon, 27 May 1996 09:07:30 -0400 (EDT) Resent-Date: Mon, 27 May 1996 09:07:30 -0400 (EDT) From: Zefram Message-Id: <20765.199605271307@stone.dcs.warwick.ac.uk> Subject: Re: (NULL == 0) ? To: hzoli@cs.elte.hu (Zoltan Hidvegi) Date: Mon, 27 May 1996 14:07:05 +0100 (BST) Cc: A.Main@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu In-Reply-To: <199605270000.CAA00847@hzoli.ppp.cs.elte.hu> from "Zoltan Hidvegi" at May 27, 96 02:00:28 am X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]7567.73 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"2madk1.0.FL6.HaQgn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1188 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu >Does anything guarantees that on those (theoretical) systems where NULL is >not really zero, all static and external pointers are initialized to this >NULL? There are many many places where this assumption is used. Yes. All variables with static duration are initialised as if they had been explicitly initialised with `= 0', so integers get 0, floating point variables get a floating point 0.0, and pointers get NULL. >Does anyone heard about such a Unix system? I bet that if such a system >exists memset would be just the easiest among many other problems. The only significant problems I am aware of are use of memset/calloc, and assumptions about the result of treating a pointer as an integer. I'm pretty sure zsh never casts a pointer to an integral type, so memset/calloc is the only thing we need to worry about. >A couple of other questions about Unix and C standards: does anything >guarantee that a variable is always 8 * sizeof(var) bits long? Only if a byte is 8 bits long and there are no holes in the integral types. This type of holes are very rare, and we assume 8 bit bytes elsewhere. I don't think we actually assume this directly anyway. > Does any >Unix or C standard guarantee that ASCII is used (zsh assumes ASCII in many >places)? No. That is certainly an issue, but it's going to be very difficult to resolve. > Does any Unix or C standard guarantees that an int always has at >least 32 bits? No. But C guarantees that long is at least 32 bits, so if there's anywhere we need 32 bits we should change it to use long. I don't know of anywhere in zsh tht needs fixing in this respect. The C standard guarantees the following: CHAR_BIT >= 8 SCHAR_MAX >= 0x7f SCHAR_MIN <= -0x7f UCHAR_MAX >= 0xff There are no holes in char. SHRT_MAX >= 0x7fff SHRT_MIN <= -0x7fff USHRT_MAX >= 0xffff I.e. short is at least 16 bits. INT_MAX >= 0x7fff INT_MIN <= -0x7fff UINT_MAX >= 0xffff I.e. int is at least 16 bits. LONG_MAX >= 0x7fffffff LONG_MIN <= -0x7fffffff ULONG_MAX >= 0xffffffff I.e. long is at least 32 bits. It is further guaranteed that SCHAR_MAX SHRT_MAX INT_MAX LONG_MAX is a nondecreasing sequence, as is UCHAR_MAX USHRT_MAX UINT_MAX ULONG_MAX, and SCHAR_MIN SHRT_MIN INT_MIN LONG_MIN is a nonincreasing sequence. The definition of the standard library indirectly requires SHRT_MAX >= UCHAR_MAX. The maximum values of the unsigned types are required to be of the form 2^n-1, where n is an integer. There are also some requirements relating each unsigned type to its signed counterpart -- basically Ufoo_MAX > foo_MAX. sizeof(char) sizeof(short) sizeof(int) sizeof(long) is also required to be a nondecreasing sequence, and for each integral type sizeof(unsigned foo) == sizeof(signed foo). -zefram