zsh-workers
 help / color / mirror / code / Atom feed
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



  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).