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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,8fd45d32d7c94df3
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,UTF8
Path: 
 g2news2.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: User Defined Storage Pool : did you ever experiment with it ?
Date: Sat, 22 Jan 2011 15:13:40 +0000
Organization: A noiseless patient Spider
Message-ID: <m24o91km3f.fsf@pushface.org>
References: <op.vpont3pqule2fv@garhos>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx01.eternal-september.org;
 posting-host="dFCm8HWntFqmDIilBLqEJQ";
	logging-data="4732"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19KSaoGWbsJt+z/h6jWf40bDA47tURhA2M="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin)
Cancel-Lock: sha1:HWXL7/nOXNG/X/+h/203GHaXYcI=
	sha1:ZU2rDjy8dvEdwH/dnSyGsI7P7Os=
Xref: g2news2.google.com comp.lang.ada:17609
Date: 2011-01-22T15:13:40+00:00
List-Id: <comp.lang.ada>

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> I don't feel to remember I ever see a single Ada source with some use
> of this. Is this just an not enough known feature, or does it mean
> there is not so much benefit to use it ? Or else, may be this could be
> beneficial but no one never go up to there (no evaluation of this
> option, or anything else) ?

The Booch Components (https://sourceforge.net/projects/booch95/) have
always required users to provide storage pools (except for Bounded
forms). I expect that most people who use(d) the BCs use(d) the one
provided, which is a wrapper for the system storage pool.

However, while developing code on Windows for use in VxWorks, we found
that the Windows allocator would zero-fill, while the VxWorks allocator
did no initialization (which is perfectly legal, of course). The result
was that uninitialized record components would appear to work on Windows
and crash mysteriously on the target.

What we did to work round this (which was before GNAT offered pragma
Initialize_Scalars and -gnatV) was to provide a specialised storage pool
which fills requested memory with 16#deadbeef#; so any uninitialized
fields are (a) reasonably unlikely to correspond to reasonable values,
(b) reasonably easy to spot in a store dump, (c) wrong on either OS.