Re: How to exit an Ada program with (unix shell) error code?

[anon@anon.org (anon)]

First, the RM (Ada 2005).  There are places that allow a vendor to replace or 
alter and in some case even remove packages from the core Ada system. 
Note: Most packages allow a vendor to add to a package aka altering the 
package.

RM 1.1.2 ( 3, 17 ) states that section 13 is apart of the core that shall be 
include, but RM 13.8 (8) states that System.Machine_Code is not required 
aka it can be removed.

8  An implementation may place restrictions on code_statements. An
implementation is not required to provide package System.Machine_Code.


Now, in the case of, Ada.Command_Line, RM A.15 (21) states:

21  An alternative declaration is allowed for package Command_Line if
different functionality is appropriate for the external execution 
environment.

Now a program that is an OS or boot loader or Kernel/System module can be 
classified as having appropriate "external execution environment" that allows 
for an "alternative declaration" of the Ada.Command_Line package. Which 
allows the vendor to dis-allow the Ada.Command_Line as defined in 
RM A.15 (2-15) because in this package the Argument_Count, Argument, and 
Command_Name are not defined and they would not have a valid routine 
address for an OS or System Module type of "external execution environment" 
(illegal in Ada). 
Plus, using the returned value of a function (main subprogram) as the 
"exit_status" complies with the "alternative declaration" stated in the 
RM A.15 (21), which replaces the Ada.Command_Line.Set_Exit_Status 
routine with a function return.

So, a vendor can alter or even remove this package. Especially for those 
compiler that are use to write modules or OS type of programs.

But does this comply with RM 1.1.2 (17).  The answer is Yes, because  
RM A.15 (21) allows an "alternative declaration".



Now, If the main subprogram is a function the binder creates the binding 
routine like:

  function main

    -- temp storage for exit status returned from main subprogram
    Status : integer ;  

    begin
      Adainit ;
      Status := <User Main function> ; -- main subprogram 
      Adafinal ; 
      return Status ;  -- returns aka "exit status" from main subprogram  
    end ;

So if the main subprogram is a function the returned value is the "exit_status" 
is passed to the OS after Adafinal has preform finalization. 

And in some cases, elaboration is not needed which means AdaInit is not 
needed and in a few rare cases finalization is not necessary, which means 
the Status can be passed directly to the OS or program loading routine. In 
these types of programs the binder could create a optimization binder file 
as:

  function main

    begin
      return <User Main function> ; -- main subprogram 
    end ;


In <be920df0-fd82-481f-9899-e70d5a968b29@v35g2000pro.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:
>On May 7, 2:08 am, a...@anon.org (anon) wrote:
>> There are basic three types of programs for computers.
>>
>>         The first, are the "Stand-Alone" programs aka OS types, which do not
>>         return and have no needs for Ada.Command_Line routines.  In order
>>         words, there are no links for the Ada.Command_Line package and the
>>         Set_Exit_Status routine.
>>
>>         The second type are "Device Drivers" or "System/Kernel" installable
>>         "Modules".  And the Ada.Command_Line package is not legal. But the
>>         Kernel requires the "Module" to notify the kernel by using the
>>         "exit status" so that the kernel can know if it should reclaim the
>>         memory, etc, on errors. Using a "function" type of module install
>>         program is the only way a "Module" can be written and have an
>>         "exit status".
>>
>>         Note: Ada as a computer language should be allowed to create
>>               these type of programs which means that Ada needs to
>>               support main subprogram that are functions.
>
>But you're ignoring a point I already made.  Since library-level
>finalizations need to be done after the main subprogram is completed,
>the Ada main subprogram cannot exit directly to the OS.  Therefore it
>really doesn't matter whether Ada main subprograms can be functions or
>not.  For an OS that expects its program to return a status in its
>"function result" register, the requirement is that the code generated
>by the compiler, that *does* exit back to the OS, has to put a status
>in that register.  And there's no reason the compiler can't generate
>code that generates this status based on the parameter to the last
>Ada.Command_Line.Set_Exit_Status call (if any), whether or not the
>main subprogram is a function.  If you still think that
>Ada.Command_Line might not be available, read on.
>
>
>>         And since there are times where the Ada.Command_Line package is
>> not available
>
>Ada.Command_Line is defined in Annex A.  Please read RM 1.1.2(2-6) and
>1.1.2(17).  I'm surprised you'd say the above, since you're fond of
>saying there are only a couple of Ada compilers out there since a
>compiler that doesn't support all of the new Ada 2005 features is not
>an Ada compiler---well, a compiler that doesn't support all of Annex A
>(including Ada.Command_Line) is not an Ada compiler either, so why
>would you be concerned about that?
>
>                                 -- Adam