From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7b69a8818c20ab9f
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: Y21C Bug
Date: 2000/01/13
Message-ID: <2000Jan13.135824.1@eisner>#1/1
X-Deja-AN: 572217700
References: <84nqbo$q28$1@nnrp1.deja.com>
 <84o0g2$u8v$1@nnrp1.deja.com>	<84pvrs$7q1@ftp.kvaerner.com>
 <wccg0wfb02q.fsf@world.std.com>	<84sltt$7s3@ftp.kvaerner.com>
 <84t966$be0$1@nnrp1.deja.com>	<84vev2$7p4@ftp.kvaerner.com>
 <38737352.B282CC2@easystreet.com>	<851j2q$78q1@ftp.kvaerner.com>
 <852dt0$vdl$1@nnrp1.deja.com>	<wcc66x7w220.fsf@world.std.com>
 <87iu16yxv4.fsf@deneb.cygnus.argh.org>	<wcciu157w2h.fsf@world.std.com>
 <387B0AC9.AA4E090B@mail.com> <wccvh50o84a.fsf@world.std.com>
 <387BC729.9F02FEF1@mail.com> <387dfb1e.cbbf14c7@mail.com>
X-Trace: news.decus.org 947789909 12207 KILGALLEN [216.44.122.34]
Organization: Digital Equipment Computer User's Society
Followup-To: <387dfb1e.cbbf14c7@mail.com>
Newsgroups: comp.lang.ada
Date: 2000-01-13T00:00:00+00:00
List-Id: <comp.lang.ada>

Reply-To: Kilgallen@eisner.decus.org.nospam
Organization: LJK Software
Lines: 23

In article <387DFB1E.CBBF14C7@mail.com>, Mats Weber <matsw@mail.com> writes:
> Thierry Lelegard wrote:
> 
>> Yes it does. If you had left the variable uninitialized (on an Ada
>> perspective), then the variable would have been allocated in
>> a "demand zero" section (no allocation in executable). Since
>> you provided an explicit initial value, the compiler/linker placed
>> it into a "copy on reference" section which contains the initial
>> values. Of course, the compiler could make a special optimization
>> which consists in inspecting every single byte of this initial
>> value and if they are all zeroes then place the variable into
>> a "demand zero" section. But, it appears that this optimization
>> is not made.
> 
> You generally cannot guarantee that the variable is allocated in a
> demand-zero region. For instance, when allocated on the stack, the stack
> may have previously grown higher than where you allocate and you get the
> content left there from a previous call (unless the stack is zeroed or
> unmapped from the address space when it shrinks, but I doubt any system
> is doing that).

You cannot guarantee a _stack_ variable is in a demand-zero region,
but you can guarantee it for static variables or by calling $EXPREG.