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 JAA28765 for <mason@werple.mira.net.au>; Tue, 28 May 1996 09:01:09 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id SAA03400; Mon, 27 May 1996 18:54:56 -0400 (EDT)
Resent-Date: Mon, 27 May 1996 18:54:56 -0400 (EDT)
From: Zefram <A.Main@dcs.warwick.ac.uk>
Message-Id: <26886.199605272254@stone.dcs.warwick.ac.uk>
Subject: Re: (NULL == 0) ?
To: hzoli@cs.elte.hu (Zoltan Hidvegi)
Date: Mon, 27 May 1996 23:54:34 +0100 (BST)
Cc: A.Main@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu
In-Reply-To: <199605272241.AAA02676@bolyai.cs.elte.hu> from "Zoltan Hidvegi" at May 28, 96 00:41:30 am
X-Loop: zefram@dcs.warwick.ac.uk
X-Stardate: [-31]7569.77
X-US-Congress: Moronic fuckers
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"6tQNK3.0._q._AZgn"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1202
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

>Bart wrote that ANSI C guarantees ASCII in the cases we need so that should
>not cause any problems.

C doesn't guarantee *any* use of ASCII.  It does make some guarantees
about the character set, but nothing involving actual ASCII.
(Basically, all the characters that C uses, plus the characters with
escapes like '\a', must be in the character set and distinct, and none
may have the value 0.)

>                         I do not see where is is assumed that a char has 8
>bits othar than buffer sizes.  We do assume that char has at least 8 bits
>but that's OK.

ZLE has some 256 element tables indexed by unsigned chars that are read
from the tty.  If char has more than 8 bits, the tables need to be made
bigger.  There are a couple of `& 0xff's, but they're easily fixed.


>Here struct iparam is used for initialisation.  It is used instead of
>struct param since initialisation of a union might cause problems.

There's definitely a problem here.  sizeof(long) > sizeof(void *) isn't
an unreasonable situation.  In fact, it makes a great deal of sense to
have 64-bit longs and 32-bit pointers on Sparc processors.  On Sparc
v9, the natural size of int and void * is 64 bits (though 32-bit
pointers are still possible), and 128-bit longs would be sensible.  As
a union isn't usable here, should we perhaps have two distinct iparam
types, one for integers and one for pointers?

-zefram