comp.lang.ada
 help / color / mirror / Atom feed
From: Ken Garlington <73672.2025@COMPUSERVE.COM>
Subject: Elaboration
Date: Fri, 28 Oct 1994 20:48:07 EDT
Date: 1994-10-28T20:48:07-04:00	[thread overview]
Message-ID: <941029004807_73672.2025_DHR55-2@CompuServe.COM> (raw)

I suspect that the following nasty behavior of our Ada83 compiler is legal, but
just in case, I wanted to ask an Ada-literate crowd:

Several applications using our compiler have ended up writing code like the
following (apologies in advance for any stupid typos, etc.) Note that the
package specs, bodies, and subunits are all compiled separately:

-------------------

package UNO is

  function IS_REALLY_SIMPLE return BOOLEAN;
  pragma INLINE(IS_REALLY_SIMPLE);

  procedure DO_SOMETHING;

end UNO;

package body UNO is

  function IS_REALLY_SIMPLE return BOOLEAN is
  begin
     -- simple one-line return statement
  end IS_REALLY_SIMPLE;

  procedure DO_SOMETHING is separate;

end UNO;



package DOS is

  function IS_REALLY_SIMPLE return BOOLEAN;
  pragma INLINE(IS_REALLY_SIMPLE);

  procedure DO_SOMETHING;

end DOS;

package body DOS is

  function IS_REALLY_SIMPLE return BOOLEAN is
  begin
     -- simple one-line return statement
  end IS_REALLY_SIMPLE;

  procedure DO_SOMETHING is separate;

end DOS;



with DOS;

separate (UNO)

procedure DO_SOMETHING is
begin

  if DOS.IS_REALLY_SIMPLE then
    -- etc.
  end if;

end DO_SOMETHING;



with UNO;

separate (DOS)

procedure DO_SOMETHING is
begin

  if UNO.IS_REALLY_SIMPLE then
    -- etc.
  end if;

end DO_SOMETHING;

-------------------

When we link all this together, the linker fails with a message that UNO and
DOS have a circular dependency in the elaboration. If we remove one of the
pragma INLINEs, this allows one of the bodies to not be compiled prior to use
of the corresponding function IS_REALLY_SIMPLE, so all is well. However, this
still seems silly to me, and other compilers can compile and link this
application without problem. We tried to think of a way to use pragma ELABORATE
to fix this, but couldn't.

What does everyone think? Should we expect the linker to have a problem with
this? Is there a simple fix to the source, other than removing an INLINE?



             reply	other threads:[~1994-10-29  0:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-10-29  0:48 Ken Garlington [this message]
1994-10-30 13:39 ` Elaboration Robert Dewar
     [not found] <941029004807_73672.2025_DHR55-2@compuserve.com>
1994-10-31 15:23 ` Elaboration Tucker Taft
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox