Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: (NULL == 0) ?
- X-seq: zsh-workers 1202
- From: Zefram <A.Main@xxxxxxxxxxxxxxxxx>
- To: hzoli@xxxxxxxxxx (Zoltan Hidvegi)
- Subject: Re: (NULL == 0) ?
- Date: Mon, 27 May 1996 23:54:34 +0100 (BST)
- Cc: A.Main@xxxxxxxxxxxxxxxxx, zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <199605272241.AAA02676@xxxxxxxxxxxxxxxxx> from "Zoltan Hidvegi" at May 28, 96 00:41:30 am
>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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author