> Now the question is how to fix this for real.
As far as I can see, the binder is indeed generating a call to
osint__m___elabb before osint___elabb, so this is probably working elsewhere
because Running_Program is probably initialized by the loader.
I would suggest reducing the bug as much as po
Laurent GUERBY writes:
> If I'm guessing correctly there are two solutions:
>
> 1/ Remove the default initialization in ada/osint.adb
> - Running_Program : Program_Type := Unspecified;
> + pragma Warnings (Off);
> + Running_Program : Program_Type;
> + pragma Warnings (On);
>
> This is no
Laurent GUERBY wrote:
If I'm reading it correctly, osint body is elaborated after osint.m one,
so there seem to be a bug.
I agree, looks like a bug
May be it doesn't trigger because in some
condition/platform no code is needed at runtime for the default
initialization of integer variables b
(I indeed forgot about the static model which is the default for GNAT)
On Sat, 2005-10-01 at 08:37 -0400, Robert Dewar wrote:
> [...] You can of course check the order of elaboration by
> looking at it. I would be surprised if there were a
> bug in the statid elab model for such a simple case,
> a
Laurent GUERBY wrote:
However I see no reason why Osint body elaboration must be done
before Osint.M body elaboration, it seems to me that the
binder could perfectly choose to elaborate Osint.M body
before Osint body, and this would leave Running_Program
with the "wrong" value Rainer observes wh
Rainer tracing seems to show that strange thing happen to
Osint.Running_Program during elaboration of 4.0.x. We have:
package body Osint is
Running_Program : Program_Type := Unspecified;
...
procedure Set_Program (P : Program_Type) is
begin
...
Running_Program := P;
end Set_Prog
