Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: hzoli change: $foo:s//r/
- X-seq: zsh-workers 327
- From: Zefram <A.Main@xxxxxxxxxxxxxxxxx>
- To: hzoli@xxxxxxxxxx (Zoltan Hidvegi)
- Subject: Re: hzoli change: $foo:s//r/
- Date: Wed, 16 Aug 1995 23:22:37 +0100 (BST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx (Z Shell workers mailing list)
- In-reply-to: <199508161824.UAA23510@xxxxxxxxxxxxxxxxx> from "Zoltan Hidvegi" at Aug 16, 95 08:24:21 pm
>Yes, it is really a good idea. But if it is really guaranteed that externs
>are initialized to zere therese initializations are unnecessary. The fact
>that zsh worked so far shows that it is quite safe to assume that global
>variables are initialized to zero, but what is in the ANSI-C standard?
ANSI requires that all objects of static storage duration (i.e.
non-auto variables) are initialised to zero(*), except when explicitly
initialised to something else. (*) Integers are initialised to
all-bits zero, which is numerically zero, but floating-point values are
initialised to floating-point zero, and pointers are initialised to a
NULL value which is not required to be all-bits zero.
This requirement has existed throughout C's lifetime; it initially
appeared, I think, because such variables under Unix are put in the BSS
area, which the kernel initialises to all-bits zero. The ANSI
committee had no choice but to uphold the assumption made by most C
programmers that this initialisation would take place, but they made
the required initialisation effectively "numerically zero" rather than
"all-bits zero" because of the unspecified nature of pointer and
floating-point representations.
Under Unix it's quite safe to assume that this initialisation will
happen (to all-bits zero, which under Unix is good for a NULL pointer)
even in languages that make no such guarantee.
-zefram
Messages sorted by:
Reverse Date,
Date,
Thread,
Author