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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Why can't objects be static in Ada?
Date: Fri, 12 Apr 2019 09:12:21 +0100
Organization: A noiseless patient Spider
Message-ID: <lylg0ffxqy.fsf@pushface.org>
References: <b411a770-5e86-4d5e-9e43-e52843be724d@googlegroups.com>
	<q8og92$1u7$1@franka.jacob-sparre.dk>
	<f572578d-1e73-4b20-b2be-e5b80a8d95b3@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org;
 posting-host="dc512dacd0b8dc2e8b3e2c7077e11c86";
	logging-data="25075"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1850BkhFOS+MAmrCR+hCnXuIw0Z0FBB7j0="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin)
Cancel-Lock: sha1:TnoljlCCtJMaU1O3VtB5tCFV5Hk=
	sha1:m6+mVt8GTbOaGI7zGpMdiYR4BeE=
Xref: reader01.eternal-september.org comp.lang.ada:56121
Date: 2019-04-12T09:12:21+01:00
List-Id: <comp.lang.ada>

Mark Lorenzen <mark.lorenzen@gmail.com> writes:

> On Friday, April 12, 2019 at 12:49:07 AM UTC+2, Randy Brukardt wrote:
>> 
>> fix this. There's no good reason (outside of Annex E issues) for
>> declaring any package preelaborated, unless you like fighting errors
>> a lot. C.4 is a load of hooey, it's not actually implementable on the
>> margins, and there's no reason for any compiler to generate more code
>> than necessary. Ergo, you'll most likely get the same code whether or
>> not you declare something Preelaborated, so why bother with all of
>> the hassles?
>
> For certification purposes, I think there is a value in avoiding
> elaboration code.
>
> http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx/support_for_certified_systems.html#avoiding-elaboration-code

This is the GNAT-specific No_Elaboration_Code restriction (and pragma
No_Elaboration_Code_All[1]) which I had to apply to the units involved
in setting up the MCU and arranging to run the compiler-generated
elaboration sequence.

[1]: This is a program unit pragma (there is also an equivalent aspect
of the same name) that establishes the restriction No_Elaboration_Code
for the current unit and any extended main source units (body and
subunits). It also has the effect of enforcing a transitive application
of this aspect, so that if any unit is implicitly or explicitly with’ed
by the current unit, it must also have the No_Elaboration_Code_All
aspect set. It may be applied to package or subprogram specs or their
generic versions.