From: Zefram <A.Main@dcs.warwick.ac.uk>
To: hzoli@cs.elte.hu (Zoltan Hidvegi)
Cc: A.Main@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu
Subject: Re: (NULL == 0) ?
Date: Mon, 27 May 1996 14:07:05 +0100 (BST) [thread overview]
Message-ID: <20765.199605271307@stone.dcs.warwick.ac.uk> (raw)
In-Reply-To: <199605270000.CAA00847@hzoli.ppp.cs.elte.hu> from "Zoltan Hidvegi" at May 27, 96 02:00:28 am
>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
next prev parent reply other threads:[~1996-05-27 13:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-05-25 14:38 clwords bugfix Zefram
1996-05-25 18:02 ` Richard Coleman
1996-05-25 20:52 ` Zefram
1996-05-25 21:25 ` (NULL == 0) ? Richard Coleman
1996-05-25 22:00 ` Zefram
1996-05-27 0:00 ` Zoltan Hidvegi
1996-05-27 6:39 ` Bart Schaefer
1996-05-27 7:29 ` anthony baxter
1996-05-27 13:07 ` Zefram [this message]
1996-05-27 22:00 ` Zoltan Hidvegi
1996-05-27 22:11 ` Zefram
1996-05-27 22:41 ` Zoltan Hidvegi
1996-05-27 22:54 ` Zefram
1996-05-28 4:54 ` Bart Schaefer
1996-05-27 23:36 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20765.199605271307@stone.dcs.warwick.ac.uk \
--to=a.main@dcs.warwick.ac.uk \
--cc=hzoli@cs.elte.hu \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).