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

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

[reinkor]

I want to use Ada programs within unix/linux makefiles and shell
scripts.
Then these programs must sometimes exit with an exit code (error
status)
so execution of the Makefile/scripts halts.

How I do this ?

reinert

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

[Samuel Tardieu]

>>>>> "Reinert" == reinkor  <reinkor@gmail.com> writes:

Reinert> I want to use Ada programs within unix/linux makefiles and
Reinert> shell scripts.  Then these programs must sometimes exit with an
Reinert> exit code (error status) so execution of the Makefile/scripts
Reinert> halts.

Reinert> How I do this ?

Ada.Command_Line.Set_Exit_Status(your_integer);

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

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

[reinkor]

On 4 Mai, 11:17, Samuel Tardieu <s...@rfc1149.net> wrote:
> >>>>> "Reinert" == reinkor  <rein...@gmail.com> writes:
>
> Reinert> I want to use Ada programs within unix/linux makefiles and
> Reinert> shell scripts.  Then these programs must sometimes exit with an
> Reinert> exit code (error status) so execution of the Makefile/scripts
> Reinert> halts.
>
> Reinert> How I do this ?
>
> Ada.Command_Line.Set_Exit_Status(your_integer);
>
>   Sam
> --
> Samuel Tardieu -- s...@rfc1149.net --http://www.rfc1149.net/

Thanks, but how I terminate the program in a "natural" way
(without using goto or "raise exception") ?

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

[Ludovic Brenta]

reinkor wrote on comp.lang.ada:
> Thanks, but how I terminate the program in a "natural" way
> (without using goto or "raise exception") ?

Simply allow the execution to reach the "end;" of the main subprogram.

with Ada.Command_Line;
procedure Exit_With_False is
begin
   Ada.Command_Line.Set_Exit_Status (1); -- False, in shell terms
end Exit_With_False; -- nothing else required

--
Ludovic Brenta.

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

[reinkor]

On 4 Mai, 11:31, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> reinkor wrote on comp.lang.ada:
>
> > Thanks, but how I terminate the program in a "natural" way
> > (without using goto or "raise exception") ?
>
> Simply allow the execution to reach the "end;" of the main subprogram.
>
> with Ada.Command_Line;
> procedure Exit_With_False is
> begin
>    Ada.Command_Line.Set_Exit_Status (1); -- False, in shell terms
> end Exit_With_False; -- nothing else required
>
> --
> Ludovic Brenta.

OK, using "return" ?

reinert

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

[Martin]

On May 4, 10:47 am, reinkor <rein...@gmail.com> wrote:
> On 4 Mai, 11:31, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
> > reinkor wrote on comp.lang.ada:
>
> > > Thanks, but how I terminate the program in a "natural" way
> > > (without using goto or "raise exception") ?
>
> > Simply allow the execution to reach the "end;" of the main subprogram.
>
> > with Ada.Command_Line;
> > procedure Exit_With_False is
> > begin
> >    Ada.Command_Line.Set_Exit_Status (1); -- False, in shell terms
> > end Exit_With_False; -- nothing else required
>
> > --
> > Ludovic Brenta.
>
> OK, using "return" ?
>
> reinert

No need for a return. But remember to ensure any tasks have completed
too.

Cheers
-- Martin

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

[sjw]

On May 4, 10:54 am, Martin <martin.do...@btopenworld.com> wrote:
> On May 4, 10:47 am, reinkor <rein...@gmail.com> wrote:

> > OK, using "return" ?
>
> > reinert
>
> No need for a return. But remember to ensure any tasks have completed
> too.
>
> Cheers
> -- Martin

You could say (in the main procedure)

  if Need_To_Quit then
     Set_Exit_Status (1);
     return;
  end if;

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

[stefan-lucks]

On Mon, 4 May 2009, Ludovic Brenta wrote:

> reinkor wrote on comp.lang.ada:
> > Thanks, but how I terminate the program in a "natural" way
> > (without using goto or "raise exception") ?
> 
> Simply allow the execution to reach the "end;" of the main subprogram.
> 
> with Ada.Command_Line;
> procedure Exit_With_False is
> begin
>    Ada.Command_Line.Set_Exit_Status (1); -- False, in shell terms

     Ada.Command_Line.Set_Exit_Status (Ada.Command_Line.Failure);

> end Exit_With_False; -- nothing else required

I believe, it is preferable to use the predefined constants "Success" and 
"Failure" in Ada.Command line:

  1. If you port your program to another (i.e. non-unix) system, 
     it is not clear that "1" maintains the logical value "False". 
     (Perhaps the RM is clear about that -- I didn't check ...) 

  2. Without the comment "-- False, in shell terms", many readers 
     (except for unix-shell experts, of course) would rather expect 

       Ada.Command_Line.Set_Exit_Status (1);

     to indicate a positive result ("True"), rather then "False". 

Here is a slightly larger example:

with Ada.Command_Line;
procedure False_If_No_Arguments is
   package ACL renames Ada.Command_Line;
begin
   if ACL.Argument_Count > 0 then
      ACL.Set_Exit_Status (ACL.Success);
   else
      ACL.Set_Exit_Status (ACL.Failure);
   end if;
end False_If_No_Arguments;

P.S.: (As you see, you can indicate either a positive or a negative 
outcome without ever having to raise an exception ...)



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

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

[Robert A Duff]

reinkor <reinkor@gmail.com> writes:

> Thanks, but how I terminate the program in a "natural" way
> (without using goto or "raise exception") ?

You can call OS_Exit or OS_Abort in GNAT.OS_Lib.  Look at the comments
to see misc subtle issues.

Or you can use pragma Import to interface directly to the OS
exit routine, if you're on an OS that has such (most do).

Or you can raise an exception, handle it at the bottom of the main
procedure, and then just drop off the end.  But you need to make
sure any tasks will terminate -- the main procedure will wait for
that, and if they never terminate, it will wait forever.

Or you can abort the environment task.

- Bob

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

[Martin]

On May 4, 2:42 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> reinkor <rein...@gmail.com> writes:
> > Thanks, but how I terminate the program in a "natural" way
> > (without using goto or "raise exception") ?
>
> You can call OS_Exit or OS_Abort in GNAT.OS_Lib.  Look at the comments
> to see misc subtle issues.

But that's not a "natural" way, as you may not be using GNAT.

Perfectly portable, if you don't mind writing the packages yourself if
you don't have access to the GNAT packages but not 'vanilla Ada'.

Is there any Ada1Z work on providing common OS services?

Cheers
-- Martin

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

[anon]

The answer is that No Language will ever standardize the OS routines or 
hardware IO interface.  

This is just one of many reasons that could easily fill a book on why!

This is because no language can insure that all of the OS routines will exist 
in furture version of an OS. Or if the hardware will be supported in that OS. 
Except for the keyboard, video, and the 3 kinds of file types. So, GNAT 
packages such as GNAT.Sockets package which should be moved to 
System.Sockets will never be standardize because how long before computer 
industry replaces the "Sockets" with another better I/O subsystem.

Just like, when industry mainly replaced both the "Serial" and "Parallel" 
ports with the more advanced serial port called "USB". Also, they mainly 
replaced the bus mouse and ps keyboards with an USB version. Now to the 
system programmer it just add an extra I/O layer they must deal with.  But 
to the normal programmer that is no change on how to access the keyboard 
or mouse, it all transpaent.

Another reason is what type of standard.

There are a few system programmers that would like to see that all 
devices be declare as a stream devices.  Could you see a programmer 
using System.Device_IO package built using Ada.Streams and opening a 
camera device or reading a steam camera device.

    package Camera_IO is new Ada.Device_IO (Camera_type);
    ...
    -- Attach (Open) the first camera using USB port to Cam_1 

    Camera_IO.open ( Cam_1, In_File, "usb://camera" ) ;


or download a picture by using the following routine

    Cam_1 : Camera_Type ;
    Pic_1 : Camera_JPG  ;
    ...
    Camera_JPG'Read ( Cam_1, Pic_1 ) ;




In <5d91dc13-6512-4d91-be5e-f9046917cd33@s31g2000vbp.googlegroups.com>, Martin <martin.dowie@btopenworld.com> writes:
>On May 4, 2:42=A0pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>> reinkor <rein...@gmail.com> writes:
>> > Thanks, but how I terminate the program in a "natural" way
>> > (without using goto or "raise exception") ?
>>
>> You can call OS_Exit or OS_Abort in GNAT.OS_Lib. =A0Look at the comments
>> to see misc subtle issues.
>
>But that's not a "natural" way, as you may not be using GNAT.
>
>Perfectly portable, if you don't mind writing the packages yourself if
>you don't have access to the GNAT packages but not 'vanilla Ada'.
>
>Is there any Ada1Z work on providing common OS services?
>
>Cheers
>-- Martin

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

[anon]

--
--  Besides the Ada.Command_Line you can just use functions for 
--  the instead of procedures for your nain program. This design is 
--  great for application where Command_Line is not used.
--

function work return Integer is

  begin
    return ( 0 ) ; -- no error status code
  end work ;



In <49ba30c9-a1e6-4346-8618-d256f87ac301@s31g2000vbp.googlegroups.com>, reinkor <reinkor@gmail.com> writes:
>I want to use Ada programs within unix/linux makefiles and shell
>scripts.
>Then these programs must sometimes exit with an exit code (error
>status)
>so execution of the Makefile/scripts halts.
>
>How I do this ?
>
>reinert

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

[Rob Norris]

On Mon, 04 May 2009 16:09:01 GMT, anon@anon.org (anon) wrote:

>
>--
>--  Besides the Ada.Command_Line you can just use functions for 
>--  the instead of procedures for your nain program. This design is 
>--  great for application where Command_Line is not used.
>--
>
>function work return Integer is
>
>  begin
>    return ( 0 ) ; -- no error status code
>  end work ;
>
>
>
>In <49ba30c9-a1e6-4346-8618-d256f87ac301@s31g2000vbp.googlegroups.com>, reinkor <reinkor@gmail.com> writes:
>>I want to use Ada programs within unix/linux makefiles and shell
>>scripts.
>>Then these programs must sometimes exit with an exit code (error
>>status)
>>so execution of the Makefile/scripts halts.
>>
>>How I do this ?
>>
>>reinert

Further to anon's reply, when your main program is a function, you can obviously return various
other values. I think in UNIX world anything other than 0 means an error, but one can encode
different error states of your own choosing eg:

if (not File_Exists (file)) then
	return (3); -- File not found
end if;

if (not In_Correct_Format (file)) then
	return (15); -- Dodgy file
end if;

etc...

Also see: http://www.faqs.org/docs/abs/HTML/exitcodes.html

I have a few programs that do this, that are called from scripts that use the exit code to determine
what to do next.

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

[Georg Bauhaus]

Rob Norris schrieb:
> On Mon, 04 May 2009 16:09:01 GMT, anon@anon.org (anon) wrote:
> 
>> --
>> --  Besides the Ada.Command_Line you can just use functions for 
>> --  the instead of procedures for your nain program. This design is 
>> --  great for application where Command_Line is not used.
>> --
>>
>> function work return Integer is
>>
>>  begin
>>    return ( 0 ) ; -- no error status code
>>  end work ;
>>
>>
>>
>> In <49ba30c9-a1e6-4346-8618-d256f87ac301@s31g2000vbp.googlegroups.com>, reinkor <reinkor@gmail.com> writes:
>>> I want to use Ada programs within unix/linux makefiles and shell
>>> scripts.
>>> Then these programs must sometimes exit with an exit code (error
>>> status)
>>> so execution of the Makefile/scripts halts.
>>>
>>> How I do this ?
>>>
>>> reinert
> 
> Further to anon's reply, when your main program is a function, you can obviously return various
> other values. I think in UNIX world anything other than 0 means an error, but one can encode
> different error states of your own choosing eg:

When choosing an OS specific return code mechanism
also be sure to choose the proper return type for OS's
return code values.

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

[Martin]

On May 4, 5:09 pm, a...@anon.org (anon) wrote:
> --
> --  Besides the Ada.Command_Line you can just use functions for
> --  the instead of procedures for your nain program. This design is
> --  great for application where Command_Line is not used.
> --
>
> function work return Integer is
>
>   begin
>     return ( 0 ) ; -- no error status code
>   end work ;

Be aware that this is not portable. The only main subprogram that all
compilers must support (if they support a main subprogram) is "public
parameterless library procedures" (RM2005 10.2, 29 - previous RMs have
similar requirements), i.e.

   procedure Main is
   ...

Cheers
-- Martin

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

[Adam Beneschan]

On May 5, 4:43 am, Martin <martin.do...@btopenworld.com> wrote:
> On May 4, 5:09 pm, a...@anon.org (anon) wrote:
>
> > --
> > --  Besides the Ada.Command_Line you can just use functions for
> > --  the instead of procedures for your nain program. This design is
> > --  great for application where Command_Line is not used.
> > --
>
> > function work return Integer is
>
> >   begin
> >     return ( 0 ) ; -- no error status code
> >   end work ;
>
> Be aware that this is not portable. The only main subprogram that all
> compilers must support (if they support a main subprogram) is "public
> parameterless library procedures" (RM2005 10.2, 29 - previous RMs have
> similar requirements), i.e.
>
>    procedure Main is
>    ...
>
> Cheers
> -- Martin


Right; and even if your Ada compiler *does* support functions that
return integers as main programs, and you're compiling for some
operating system with an "x" in its name (or Solaris), this does *not*
mean that the Ada compiler will treat the function result as the
status code.  The compiler could decide that the function result is
something to be formatted and spit out onto standard output.  If an
Ada implementation supports parameters and/or function results on main
programs, the language leaves it up to the implementation how those
are interpreted.  There's no rule that says that the interpretation
has to mimic the behavior of the C language (thank God).  So anon's
solution may work on GNAT, but it can't be assumed to work anywhere
else.

                                -- Adam

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

[Jean-Pierre Rosen]

Adam Beneschan a �crit :
> Right; and even if your Ada compiler *does* support functions that
> return integers as main programs, and you're compiling for some
> operating system with an "x" in its name (or Solaris), this does *not*
> mean that the Ada compiler will treat the function result as the
> status code.  The compiler could decide that the function result is
> something to be formatted and spit out onto standard output.  If an
> Ada implementation supports parameters and/or function results on main
> programs, the language leaves it up to the implementation how those
> are interpreted.  There's no rule that says that the interpretation
> has to mimic the behavior of the C language (thank God).  So anon's
> solution may work on GNAT, but it can't be assumed to work anywhere
> else.
> 
That's right from a legalistic point of view, but don't forget that
compiler writers are not masochists. If an implementation supports
functions returning integers as main programs, I would be very surprised
if it was not interpreted as the return code, since this is what the
consumer would expect...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

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

[Adam Beneschan]

On May 5, 8:34 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> Adam Beneschan a écrit :> Right; and even if your Ada compiler *does* support functions that
> > return integers as main programs, and you're compiling for some
> > operating system with an "x" in its name (or Solaris), this does *not*
> > mean that the Ada compiler will treat the function result as the
> > status code.  The compiler could decide that the function result is
> > something to be formatted and spit out onto standard output.  If an
> > Ada implementation supports parameters and/or function results on main
> > programs, the language leaves it up to the implementation how those
> > are interpreted.  There's no rule that says that the interpretation
> > has to mimic the behavior of the C language (thank God).  So anon's
> > solution may work on GNAT, but it can't be assumed to work anywhere
> > else.
>
> That's right from a legalistic point of view, but don't forget that
> compiler writers are not masochists.

That last statement might be tautologically false.  :) :) :)

In any case, if you're implying that writing the extra code needed to
get the program to display the function result on the standard output
is an act of self-inflicted pain---trust me, it's nowhere near as
painful as trying to understand and implement 3.10.2.


> If an implementation supports
> functions returning integers as main programs, I would be very surprised
> if it was not interpreted as the return code, since this is what the
> consumer would expect...

Irvine Compiler's Ada compiler (the one I masochistically work on
maintaining) does behave in the way I described.  Main subprograms can
be procedures or functions; they can take parameters that are scalars
or String (which are parsed from the command line); and they can be
functions that return scalars or String, with the result being
formatted and displayed on the standard output.  The compiler was
originally written to run on Unix and VMS---and, by the way, I'm not
sure that VMS supports the convention that a main program's function
result becomes the return status (which is not a simple zero or non-
zero as it is on Unix, if I recall correctly).  The compiler also runs
on a variety of other targets, although the parameters and function
result aren't supported in most cases.

Surprised?  Well, the compiler is consistent across platforms and with
respect to allowing various types to be used as function results.  It
wouldn't make any sense to break consistency and make integer-
returning functions on Unix-type platforms behave differently.  And
nobody has ever complained about it.  As for whether it's what I'd
expect if I were a consumer...  I'm not much of a C hack, but when I
do use C I use exit() to set the status code, not "return", which
seems to me to pervert the meaning of what a "function" and a function
result should be; or as Georg said it, it's "playing tricks" with the
language.  I don't feel any particular need to expect Ada compilers to
support the same sort of trickery C programmers are used to.

But that's just my opinion.

                              -- Adam

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

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:356247f9-4a83-44aa-a412-4500e6af19cf@f1g2000prb.googlegroups.com...
...
> In any case, if you're implying that writing the extra code needed to
> get the program to display the function result on the standard output
> is an act of self-inflicted pain---trust me, it's nowhere near as
> painful as trying to understand and implement 3.10.2.

Don't worry, as soon as you think that you've managed that, we'll (the ARG) 
change it again. Because we don't really understand it either. :-)

                 Randy.

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

[anon]

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.

        The third is "Applications" programs but runs under a command shell, 
        which contains the links for the Ada.Command_Line package. Which 
        allow a program to use Ada.Command_Line.Set_Exit_Status routine. 
        But the RM does not force a programmer to use the Set_Exit_Status 
        in Ada.Command_Line package to return the "exit status"


Note: In GNAT, using a function for the main subprogram, the return value 
      of this function will be the "exit status". And if the program 
      uses the Ada.Command_Line.Set_Exit_Status routine the value is 
      discarded.


Then you have one of the "High Priority" concepts within the Ada language 
that is the "Safety and Security" concerns which make it illegal and against 
the RM for any Ada program to cause the OS or an external environment to 
become unstable. This includes, the execution of the Ada programs, or the 
result of its exiting. Now returning a "exit status" help keep the OS 
stable. Because the "exit status" can informs the OS if it needs to perform 
any error recovery processes on the resources used by the Ada program before 
reclaiming that resource, such as closing files that Ada can not close or 
reset devices that Ada has no knowledge of how to do.

        And since there are times where the Ada.Command_Line package is 
not available, there has to be a way to send a "exit status" to the OS 
in those case. The easiest is to use function type of "main subprograms" 
which returns the program "exit status".  One reason is if the Ada 
programmer, is using a "close source" Ada RTL there is no way of knowing 
how to perform a Set_Exit_Status for that version of Ada. 

Note: Is Ada becoming like C!!!! 

        Ada does allow some tricks that makes it more like C's nasty little 
tricks. Like using "pragma Import" and "pragma Export" within Ada to Ada 
packages which bypasses Ada package design structure is one. GNAT loves 
this one in the GNAT RTL. This also, can cause errors in the elaboration 
order which may result in other problems.

        Also, another one is in all of the GNAT programs (like gnatmake, 
gnatbind, gnatlink to name three) in the GNAT package are using a 
File_Descriptor type and direct to C type of IO routines which are defined 
in the System.OS_LIB or the older GNAT.OS_LIB package. These are not apart
of the RM.   Why did they not just use "File_Type" from either Ada.Text_IO, 
Ada.Direct_IO, or Ada.Sequential_IO standard Ada packages. All source files 
and the assembly translated output files can be handled by the Ada.Text_IO 
package. While the ALI files could use either Ada.Text_IO or 
Ada.Sequential_IO package. And as for the objects files, well in the 
GNAT design, all object files are created by the gcc "as", and are linked 
with either the gcc's "collect2" or "ld" be default. 

Note: There are options for other version of linkers, but GNATLINK 
defaufts to gcc's "collect2" or "ld". 

        Actually it seams that every year more and more trashy C routines 
and data types are inserted in the packages that GNAT wants programmers to 
use. Like the C file structure and routines in the System.OS_LIB package. 
Yes, some of those have been around for years, but by now Adacore should be
rewritting then to use pure RM Ada. And provide only a limited standard 
C and OS library routines, such as may be System.Sockets.  Plus, every year 
there are always additional C files, to be interfaces C libraries and OS to Ada. 
And I notice last year the GNAT GPL 2008 had one C file that replaced a 
couple of Ada routines that were in the GNAT GPL 2007. That's going away 
from Ada back to C, that's just WRONG!


In <356247f9-4a83-44aa-a412-4500e6af19cf@f1g2000prb.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:
>On May 5, 8:34 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
>> Adam Beneschan a =E9crit :> Right; and even if your Ada compiler *does* s=
>upport functions that
>> > return integers as main programs, and you're compiling for some
>> > operating system with an "x" in its name (or Solaris), this does *not*
>> > mean that the Ada compiler will treat the function result as the
>> > status code.  The compiler could decide that the function result is
>> > something to be formatted and spit out onto standard output.  If an
>> > Ada implementation supports parameters and/or function results on main
>> > programs, the language leaves it up to the implementation how those
>> > are interpreted.  There's no rule that says that the interpretation
>> > has to mimic the behavior of the C language (thank God).  So anon's
>> > solution may work on GNAT, but it can't be assumed to work anywhere
>> > else.
>>
>> That's right from a legalistic point of view, but don't forget that
>> compiler writers are not masochists.
>
>That last statement might be tautologically false.  :) :) :)
>
>In any case, if you're implying that writing the extra code needed to
>get the program to display the function result on the standard output
>is an act of self-inflicted pain---trust me, it's nowhere near as
>painful as trying to understand and implement 3.10.2.
>
>
>> If an implementation supports
>> functions returning integers as main programs, I would be very surprised
>> if it was not interpreted as the return code, since this is what the
>> consumer would expect...
>
>Irvine Compiler's Ada compiler (the one I masochistically work on
>maintaining) does behave in the way I described.  Main subprograms can
>be procedures or functions; they can take parameters that are scalars
>or String (which are parsed from the command line); and they can be
>functions that return scalars or String, with the result being
>formatted and displayed on the standard output.  The compiler was
>originally written to run on Unix and VMS---and, by the way, I'm not
>sure that VMS supports the convention that a main program's function
>result becomes the return status (which is not a simple zero or non-
>zero as it is on Unix, if I recall correctly).  The compiler also runs
>on a variety of other targets, although the parameters and function
>result aren't supported in most cases.
>
>Surprised?  Well, the compiler is consistent across platforms and with
>respect to allowing various types to be used as function results.  It
>wouldn't make any sense to break consistency and make integer-
>returning functions on Unix-type platforms behave differently.  And
>nobody has ever complained about it.  As for whether it's what I'd
>expect if I were a consumer...  I'm not much of a C hack, but when I
>do use C I use exit() to set the status code, not "return", which
>seems to me to pervert the meaning of what a "function" and a function
>result should be; or as Georg said it, it's "playing tricks" with the
>language.  I don't feel any particular need to expect Ada compilers to
>support the same sort of trickery C programmers are used to.
>
>But that's just my opinion.
>
>                              -- Adam
>
>
>

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

[Georg Bauhaus]

anon schrieb:
> Using a "function" type of module install 
>         program is the only way a "Module" can be written and have an 
>         "exit status".

Uhm, no.

Actually, the clean up routines of modules (assuming
Linux kernel modules) have "void" return type.


>         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.

What seems needed is a way to write programs such that
they follow the conventions of the respective execution
environment; communication; interrupts; special locations;
and maybe return values.

This will necessarily depend on the execution environment,
I should think, which may or may not require *some*
subprogram to be a function with parameters, say.

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

[anon]

"Initialize_spca_Driver" is the main subprogram for this device module in 
either Ada or C versions


with Linux ;
with Linux.Modules ;
with Linux.Modules.IO ;

use  Linux ;
use  Modules ;
use  IO ;

package body spca is

.. 

-- ------------------------------------------------------------------------ --
--                         Initialize_spca_Driver                           --
--                                                                          --
-- Initialize_spca_Driver -- Initializes the loadable module.               --
--                           1.  Create and extry in the "/proc"            --
--                           2.  Registers the usb device                   --
--                                                                          --
-- ------------------------------------------------------------------------ --

  function Initialize_spca_Driver return Exit_Status is
    begin 
      Create_Proc_File_System ;

      if usb_register ( USB_Driver_Table ) then
        info ( "SPCA USB ERROR: Camera driver not installed" ) ;
                               -- Error tell kernel it can reclaim this memory 
        return Failure ; 
      end if ;
    -- It up and waiting
    info ( DRIVER_DESC & " : version " & DRIVER_VERSION ) ;
    return Success ;  
  end Initialize_spca_Driver ;
end spca ;


/* C version: from spca.c  */

/* Now, where is the void???  */


/* ************************************************************************ */
/*                         Initialize_spca_Driver                           */
/*                                                                          */
/* Initialize_spca_Driver -- Initializes the loadable module.               */
/*                           1.  Create and extry in the "/proc"            */
/*                           2.  Registers the usb device                   */
/*                                                                          */
/* ************************************************************************ */

int __init Initialize_spca_Driver ( void )
  {

#ifdef CONFIG_PROC_FS
    Create_Proc_File_System ( ) ;
#endif

    if ( usb_register ( &USB_Driver_Table ) )
      {
        info ( "SPCA USB ERROR: Camera driver not installed" ) ;
             /* notify kernel that memory can be recalmed */ 
        return -1 ; 
      }
    info ( DRIVER_DESC " : version " DRIVER_VERSION ) ;
    return 0 ;
  }




In <4a02b178$0$31872$9b4e6d93@newsspool3.arcor-online.net>, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>anon schrieb:
>> Using a "function" type of module install 
>>         program is the only way a "Module" can be written and have an 
>>         "exit status".
>
>Uhm, no.
>
>Actually, the clean up routines of modules (assuming
>Linux kernel modules) have "void" return type.
>
>
>>         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.
>
>What seems needed is a way to write programs such that
>they follow the conventions of the respective execution
>environment; communication; interrupts; special locations;
>and maybe return values.
>
>This will necessarily depend on the execution environment,
>I should think, which may or may not require *some*
>subprogram to be a function with parameters, say.

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

[Martin]

On May 7, 12:22 pm, a...@anon.org (anon) wrote:
> "Initialize_spca_Driver" is the main subprogram for this device module in
> either Ada or C versions
>
> with Linux ;
> with Linux.Modules ;
> with Linux.Modules.IO ;
>
> use  Linux ;
> use  Modules ;
> use  IO ;
>
> package body spca is
>
> ..
>
> -- ------------------------------------------------------------------------ --
> --                         Initialize_spca_Driver                           --
> --                                                                          --
> -- Initialize_spca_Driver -- Initializes the loadable module.               --
> --                           1.  Create and extry in the "/proc"            --
> --                           2.  Registers the usb device                   --
> --                                                                          --
> -- ------------------------------------------------------------------------ --
>
>   function Initialize_spca_Driver return Exit_Status is
>     begin
>       Create_Proc_File_System ;
>
>       if usb_register ( USB_Driver_Table ) then
>         info ( "SPCA USB ERROR: Camera driver not installed" ) ;
>                                -- Error tell kernel it can reclaim this memory
>         return Failure ;
>       end if ;
>     -- It up and waiting
>     info ( DRIVER_DESC & " : version " & DRIVER_VERSION ) ;
>     return Success ;  
>   end Initialize_spca_Driver ;
> end spca ;

Fine...it just isn't guarenteed to be portable.

Cheers
-- Martin

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

[Georg Bauhaus]

anon schrieb:
> "Initialize_spca_Driver" is the main subprogram for this device module in 
> either Ada or C versions
> 
> 
> with Linux ;
> with Linux.Modules ;
> with Linux.Modules.IO ;
> 
> use  Linux ;
> use  Modules ;
> use  IO ;
> 
> package body spca is
> 
> .. 
> 
> -- ------------------------------------------------------------------------ --
> --                         Initialize_spca_Driver                           --
> --                                                                          --
> -- Initialize_spca_Driver -- Initializes the loadable module.               --
> --                           1.  Create and extry in the "/proc"            --
> --                           2.  Registers the usb device                   --
> --                                                                          --
> -- ------------------------------------------------------------------------ --
> 
>   function Initialize_spca_Driver return Exit_Status is

> 
> /* C version: from spca.c  */
> 
> /* Now, where is the void???  */

These are initialization routines, not the module
cleanup routines.  The above just happens to return a
value of type Exit_Status that may or may not
coincide with what the kernel expects (unless the
name Exit_Status has been cheerfully overloaded?) :
Interfaces.C.int.  Let's hope it does.

> 
> /* ************************************************************************ */
> /*                         Initialize_spca_Driver                           */
> /*                                                                          */
> /* Initialize_spca_Driver -- Initializes the loadable module.               */
> /*                           1.  Create and extry in the "/proc"            */
> /*                           2.  Registers the usb device                   */
> /*                                                                          */
> /* ************************************************************************ */
> 
> int __init Initialize_spca_Driver ( void )
>   {

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

[Adam Beneschan]

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

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

[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

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

[Adam Beneschan]

On May 8, 3:17 am, a...@anon.org (anon) wrote:

[Note: I was out of town for a long weekend, for Mother's Day, and saw
this post just today.]

> 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.

OK, I wasn't aware of this.  But it doesn't help your case any.  In
the post to which I was responding, you said:

"And since there are times where the Ada.Command_Line package is
not available, there has to be a way to send a 'exit status' to the OS
in those case."

If the OS is such that it expects programs to return an exit status,
then certainly an alternative (or omitted) declaration of
Ada.Command_Line that did not support Set_Exit_Status would not be
"appropriate for the external execution environment".  (It would only
be appropriate in cases where there is no real OS, or if there's a
bare-bones OS that does not care about exit statuses.)  I think the
point you're trying to make is that the language should *require*
support for parameterless functions as main programs, but you still
haven't demonstrated your point; ignoring cases where the vendor just
plain screws up by providing an inappropriate version of Command_Line,
you have not shown that there is ever a need to support main programs
of this form.

                              -- Adam

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

[anon]

Well, lets see. I did answer the original poster, Adam. It just that 
Martin suggest that functions are not portable and that where you 
came in.

Now, all OS's (AT&T OS port, Linux, and Windows) shell or application 
loaders, calls a program using the following format:

 Exit_Status := Application.all ( Augment_Count, 
                                  Argument_List, 
                                  Environment_List ) ;

This is defined from the "implementation's execution environment" which 
RM 1.1.3 (6) states that if it is "impossible or impractical" then Ada
variations are permitted. Which states that all Ada partitions that are 
executed under this type of OS which calls a program as a function shall 
return a value aka Exit_Status. 

The exception is where the program exits abnormally, such as an 
"unhanded exception" or using the two exit routines 
"System.OS_LIB.OS_Exit" and "System.OS_LIB.OS_Abort".

Also RM 1.1.3 (12), strengths these calling conversion and the normal 
function type of return value. 

Then you have RM 10.2 (21) which states that Ada must conform to the 
"implementation's execution environment". By return an exit status 
unless it terminates abnormally since it was called as a function. 

10.2  (21) A call to the main subprogram, if the partition has one. If 
           the main subprogram has parameters, they are passed; where 
           the actuals come from is implementation defined. What 
           happens to the result of a main function is also 
           implementation defined.

1.1.3 (12) Any result returned or exception propagated from a main 
           subprogram (see 10.2) or an exported subprogram (see 
           Annex B) to an external caller;

1.1.3 (6)  Contain no variations except those explicitly permitted by 
           this International Standard, or those that are impossible or 
           impractical to avoid given the implementation's execution 
           environment;


Note: Hope you had a fun holiday!!!


Also for Martin.

Can a user-created procedure (main subprogram) be concerned as a "public 
parameterless library procedures.  No! The reason is that the procedure 
is not public, it first must be bound by the binding process.

10.2  (29) An implementation may restrict the kinds of subprograms it 
           supports as main subprograms. However, an implementation is
           required to support all main subprograms that are public 
           parameterless library procedures.




In <d73c38a7-8d9b-447f-a462-2aac8630c45f@v23g2000pro.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:
>On May 8, 3:17 am, a...@anon.org (anon) wrote:
>
>[Note: I was out of town for a long weekend, for Mother's Day, and saw
>this post just today.]
>
>> 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.
>
>OK, I wasn't aware of this.  But it doesn't help your case any.  In
>the post to which I was responding, you said:
>
>"And since there are times where the Ada.Command_Line package is
>not available, there has to be a way to send a 'exit status' to the OS
>in those case."
>
>If the OS is such that it expects programs to return an exit status,
>then certainly an alternative (or omitted) declaration of
>Ada.Command_Line that did not support Set_Exit_Status would not be
>"appropriate for the external execution environment".  (It would only
>be appropriate in cases where there is no real OS, or if there's a
>bare-bones OS that does not care about exit statuses.)  I think the
>point you're trying to make is that the language should *require*
>support for parameterless functions as main programs, but you still
>haven't demonstrated your point; ignoring cases where the vendor just
>plain screws up by providing an inappropriate version of Command_Line,
>you have not shown that there is ever a need to support main programs
>of this form.
>
>                              -- Adam

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

[Martin]

On May 14, 3:55 am, a...@anon.org (anon) wrote:
[snip]
> Also for Martin.
>
> Can a user-created procedure (main subprogram) be concerned as a "public

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Can you put this into English?

Cheers
-- Martin

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

[Martin]

On May 14, 3:55 am, a...@anon.org (anon) wrote:
[snip]
> Also for Martin.
>
> Can a user-created procedure (main subprogram) be concerned as a "public
> parameterless library procedures.  No! The reason is that the procedure
> is not public, it first must be bound by the binding process.
>
> 10.2  (29) An implementation may restrict the kinds of subprograms it
>            supports as main subprograms. However, an implementation is
>            required to support all main subprograms that are public
>            parameterless library procedures.

Ohhh groan.....I think I see what you're trying to say but you've got
the wrong end of the stick.

It's saying that you can't have this as a main procedure:

package Application is
private
   procedure Main;   -- NB: in private part of package-decl
end Application;

   or

package Application is
   ...
end Application;

package body Application is
   ...
   procedure Main;    -- NB: Declaration in body not spec
   ...
   procedure Main is
   ...
   end Main;
   ...
end Application;

It's not taking about binding (as nothing in the RM talks about
binding).

Cheers
-- Martin

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

[Martin]

On May 14, 9:39 am, Martin <martin.do...@btopenworld.com> wrote:
[snip]
> It's not taking about binding (as nothing in the RM talks about
> binding).

Other than to say the building mechanism is implemenation defined.

Cheers
-- Martin

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

[Ludovic Brenta]

Martin wrote on comp.lang.ada:
> On May 14, 3:55 am, a...@anon.org (anon) wrote:
> [snip]
>
> > Also for Martin.
>
> > Can a user-created procedure (main subprogram) be concerned as a "public
> > parameterless library procedures.  No! The reason is that the procedure
> > is not public, it first must be bound by the binding process.
>
> > 10.2  (29) An implementation may restrict the kinds of subprograms it
> >            supports as main subprograms. However, an implementation is
> >            required to support all main subprograms that are public
> >            parameterless library procedures.
>
> Ohhh groan.....I think I see what you're trying to say but you've got
> the wrong end of the stick.
>
> It's saying that you can't have this as a main procedure:
>
> package Application is
> private
>    procedure Main;   -- NB: in private part of package-decl
> end Application;
>
>    or
>
> package Application is
>    ...
> end Application;
>
> package body Application is
>    ...
>    procedure Main;    -- NB: Declaration in body not spec
>    ...
>    procedure Main is
>    ...
>    end Main;
>    ...
> end Application;
>
> It's not taking about binding (as nothing in the RM talks about
> binding).

The following is not a "public library procedure" either since it is
not declared at library level:

package Application is -- package at library level
   procedure Main; -- subprogram not at library level
end Applicatin;

There is another non-portable, compiler-dependent possibility which is
to not have a main subprogram at all but instead to rely on
elaboration:

package Application is
   pragma Elaborate_Body;
end Application;

package body Application is
begin
   ...
end Application;

Again the RM does not require the compiler to support this, so this is
non-portable.

--
Ludovic Brenta.

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

[Martin]

On May 14, 10:34 am, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
> Martin wrote on comp.lang.ada:
>
>
>
> > On May 14, 3:55 am, a...@anon.org (anon) wrote:
> > [snip]
>
> > > Also for Martin.
>
> > > Can a user-created procedure (main subprogram) be concerned as a "public
> > > parameterless library procedures.  No! The reason is that the procedure
> > > is not public, it first must be bound by the binding process.
>
> > > 10.2  (29) An implementation may restrict the kinds of subprograms it
> > >            supports as main subprograms. However, an implementation is
> > >            required to support all main subprograms that are public
> > >            parameterless library procedures.
>
> > Ohhh groan.....I think I see what you're trying to say but you've got
> > the wrong end of the stick.
>
> > It's saying that you can't have this as a main procedure:
>
> > package Application is
> > private
> >    procedure Main;   -- NB: in private part of package-decl
> > end Application;
>
> >    or
>
> > package Application is
> >    ...
> > end Application;
>
> > package body Application is
> >    ...
> >    procedure Main;    -- NB: Declaration in body not spec
> >    ...
> >    procedure Main is
> >    ...
> >    end Main;
> >    ...
> > end Application;
>
> > It's not taking about binding (as nothing in the RM talks about
> > binding).
>
> The following is not a "public library procedure" either since it is
> not declared at library level:
>
> package Application is -- package at library level
>    procedure Main; -- subprogram not at library level
> end Applicatin;
>
> There is another non-portable, compiler-dependent possibility which is
> to not have a main subprogram at all but instead to rely on
> elaboration:
>
> package Application is
>    pragma Elaborate_Body;
> end Application;
>
> package body Application is
> begin
>    ...
> end Application;
>
> Again the RM does not require the compiler to support this, so this is
> non-portable.
>
> --
> Ludovic Brenta.

You're quite right Ludovic - wonder if there are any more...

Cheers
-- Martin

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

[Georg Bauhaus]

Martin schrieb:

>> There is another non-portable, compiler-dependent possibility which is
>> to not have a main subprogram at all but instead to rely on
>> elaboration:


> You're quite right Ludovic - wonder if there are any more...


When the "main subprogram" is written in some other language?

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

[Adam Beneschan]

On May 13, 7:55 pm, a...@anon.org (anon) wrote:

> Now, all OS's (AT&T OS port, Linux, and Windows) shell or application
> loaders, calls a program using the following format:
>
>  Exit_Status := Application.all ( Augment_Count,
>                                   Argument_List,
>                                   Environment_List ) ;

I'll have to bow out of this argument, because you're making arguments
that I've already refuted multiple times, and you seem not to notice.
In particular, you still seem to assume that the OS is going to call
the Ada main subprogram directly, and I've dealt with this mistaken
assumption at least twice already.  I don't feel like taking time
repeating myself any more.  But I did want to point out a few places
where you're reading something in the RM that isn't there:


> This is defined from the "implementation's execution environment" which
> RM 1.1.3 (6) states that if it is "impossible or impractical" then Ada
> variations are permitted. Which states that all Ada partitions that are
> executed under this type of OS which calls a program as a function shall
> return a value aka Exit_Status.

This is a huge stretch of interpretation.  This paragraph is saying,
basically, that variations from the language are permitted if it's
impossible to implement things the way the standard says in a
particular execution environment; and you're interpreting this as a
*requirement* that the result of a function used as a main subprogram
must be an exit status.


> Then you have RM 10.2 (21) which states that Ada must conform to the
> "implementation's execution environment". By return an exit status
> unless it terminates abnormally since it was called as a function.
>
> 10.2  (21) A call to the main subprogram, if the partition has one. If
>            the main subprogram has parameters, they are passed; where
>            the actuals come from is implementation defined. What
>            happens to the result of a main function is also
>            implementation defined.

How does this state that "Ada must conform to the implementation's
execution environment", as you say?  This paragraph doesn't even
mention the execution environment.  All it says is that "what happens
to the result of a main function is implementation defined", and the
phrase "implementation defined" means pretty much "whatever the
compiler writer chooses it to mean".  If you believe "implementation
defined" means "determined in some way by the implementation's
execution environment", or "required to conform to it", well then---
sorry, you are just not familiar with commonly used computer
terminology.


> 1.1.3 (12) Any result returned or exception propagated from a main
>            subprogram (see 10.2) or an exported subprogram (see
>            Annex B) to an external caller;

The effect of this paragraph is to define the result of a main
subprogram as an "external interaction".  That's all it does.  The
section of the RM is giving a definition of the term "external
interaction".  It makes no statement about what the result should be.

                                  -- Adam

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

[anon]

Well, Adam.  


   You did not take account that when the OS calls a program, it has the 
following format, and is the only way any program or an Ada RTS will have 
access to the command line arguments and environment list.  

( written in Ada type code, but normally written in C )

     --  OS uses:   
                Exit_Status := Application.all ( Argument_Count,
                                                 Argument_List,
                                                 Environment_List ) ;

     -- Calls an application ( any language: Ada, Cobol, Fortran, etc ).

     Now, if the language is Ada. The call is to the Ada RTS (normally created 
in the binding process) for the application , which in turn calls the user's 
"main subprogram". Then normally waits until user's "main subprogram" 
returns then the RTS returns a exit_status or return code to the OS.

     RM 10.2 (21) Since, the "implementation defined" requires a return code 
and uses this value as an exit_status. Ada must comply and return a 
exit_code. 


     But an Ada programmer can create their own RTS. And this partition can 
be called directly by the OS.  Just, compile and then link, and it will be ready 
to execute.
     
     In is Ada outline ( this type of Ada main subprogram can and is called 
directly by the OS ).  This is the basic outline produced by "GNATBIND" with 
the results in b~<file>.adb|s which are directly link to the OS.

        with System ;
        function Application ( Argument_Count   : Integer ;
                               Argument_List    : System.Address ;
                               Environment_List : System.Address )
                 return Integer is


             -- Should use "with Ada.Command_Line" instead of 
             -- using "pragma Import" but that's GNAT design

             gnat_argc : Integer;
             gnat_argv : System.Address;
             gnat_envp : System.Address;
             gnat_exit_status : Integer;
             pragma Import (C, gnat_argc);
             pragma Import (C, gnat_argv);
             pragma Import (C, gnat_envp);
             pragma Import (C, gnat_exit_status);


             procedure Adainit is 
              ...
             procedure Adafinal is
              ...

          begin
            -- set up Ada.Command_Line, if package is available
            gnat_argc := Argument_Count ;
            gnat_argv := Argument_List ;
            gnat_envp := Environment_List ;

            Adainit ;  -- preform elaboration

              --  statement for the core of the user's program
              --
              --  The binder in GNAT just calls the user subroutine
              --  by pragma Import.
              --  If the call is to a function, then it returns the
              --  exit status from that function. And some of 
              --  Ada_Command_Line links are not available.

            Adafinal ; -- preform finalization
            return gnat_exit_status ;
          end Application ;


     This information is also demonstrated in Xavier Gave's toy lovelace 
series in 2004.


Note: OS_Exit and OS_Abort requires the OS to shutdown the Ada RTS and 
other application's subtasks. And the finalization will not be preformed. 

Note: In the RM implementation is define as vendor or OS and OS 
      environments.


Martin.

The RM 10.2 (29) is also, under the "Implementation Permissions" which 
means that the vendor does not have to obey the RM 10.2 (29) rule. Its  
just a strong suggestion.

Binding process is referred to a process of creating an interface from Ada 
"main subprogram" to the "implementation execution environment" aka OS 
which normally done in two phases.  The first, is using a Binder program to 
build the interface routine. And the second is to link and edit the routines 
and required packages together to build the partition. And In the simplest 
form a "Binding Process" is just another name for the linking process.  








In <d30a0294-f9a2-43ec-9cae-777995001e6c@f1g2000prb.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:
>On May 13, 7:55 pm, a...@anon.org (anon) wrote:
>
>> Now, all OS's (AT&T OS port, Linux, and Windows) shell or application
>> loaders, calls a program using the following format:
>>
>>  Exit_Status := Application.all ( Augment_Count,
>>                                   Argument_List,
>>                                   Environment_List ) ;
>
>I'll have to bow out of this argument, because you're making arguments
>that I've already refuted multiple times, and you seem not to notice.
>In particular, you still seem to assume that the OS is going to call
>the Ada main subprogram directly, and I've dealt with this mistaken
>assumption at least twice already.  I don't feel like taking time
>repeating myself any more.  But I did want to point out a few places
>where you're reading something in the RM that isn't there:
>
>
>> This is defined from the "implementation's execution environment" which
>> RM 1.1.3 (6) states that if it is "impossible or impractical" then Ada
>> variations are permitted. Which states that all Ada partitions that are
>> executed under this type of OS which calls a program as a function shall
>> return a value aka Exit_Status.
>
>This is a huge stretch of interpretation.  This paragraph is saying,
>basically, that variations from the language are permitted if it's
>impossible to implement things the way the standard says in a
>particular execution environment; and you're interpreting this as a
>*requirement* that the result of a function used as a main subprogram
>must be an exit status.
>
>
>> Then you have RM 10.2 (21) which states that Ada must conform to the
>> "implementation's execution environment". By return an exit status
>> unless it terminates abnormally since it was called as a function.
>>
>> 10.2  (21) A call to the main subprogram, if the partition has one. If
>>            the main subprogram has parameters, they are passed; where
>>            the actuals come from is implementation defined. What
>>            happens to the result of a main function is also
>>            implementation defined.
>
>How does this state that "Ada must conform to the implementation's
>execution environment", as you say?  This paragraph doesn't even
>mention the execution environment.  All it says is that "what happens
>to the result of a main function is implementation defined", and the
>phrase "implementation defined" means pretty much "whatever the
>compiler writer chooses it to mean".  If you believe "implementation
>defined" means "determined in some way by the implementation's
>execution environment", or "required to conform to it", well then---
>sorry, you are just not familiar with commonly used computer
>terminology.
>
>
>> 1.1.3 (12) Any result returned or exception propagated from a main
>>            subprogram (see 10.2) or an exported subprogram (see
>>            Annex B) to an external caller;
>
>The effect of this paragraph is to define the result of a main
>subprogram as an "external interaction".  That's all it does.  The
>section of the RM is giving a definition of the term "external
>interaction".  It makes no statement about what the result should be.
>
>                                  -- Adam

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

[Martin]

On May 15, 11:20 am, a...@anon.org (anon) wrote:
[anon]
> Martin.
>
> The RM 10.2 (29) is also, under the "Implementation Permissions" which
> means that the vendor does not have to obey the RM 10.2 (29) rule. Its  
> just a strong suggestion.

Except when the the phrase "is required" is part of the sentence.

Yes, it is in the IP section BECAUSE IT HAS TO BE - not all
environments support a 'main subprogram' => it has to be an IP to not
have one. And for that matter, to have one!

The requirement is that if an implementation does support a 'main
subprogram' then the very least it has to support is of the style
'procedure Main;'.


> Binding process is referred to a process of creating an interface from Ada
> "main subprogram" to the "implementation execution environment" aka OS
> which normally done in two phases.  The first, is using a Binder program to
> build the interface routine. And the second is to link and edit the routines
> and required packages together to build the partition. And In the simplest
> form a "Binding Process" is just another name for the linking process.  

Thanks, after nearly 20 years of Ada use, I think I'm getting the hang
of what binders and linkers do and the binder does a lot more than
just build an interface to the environment...[at least on some of the
products I've used. Can't speak for all that I have used and certainly
can't for those that I haven't used.]

Cheers
-- Martin

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

[anon]

Actually, Adam the design for all OS currectly use today states that if the 
program returns the "Accumulator Register" will contain the program exit 
code. Been a standard for at least 40 years.


In <62b174a9-c9c5-479c-9dd6-71916c102eb0@z16g2000prd.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes:
>On May 5, 4:43 am, Martin <martin.do...@btopenworld.com> wrote:
>> On May 4, 5:09 pm, a...@anon.org (anon) wrote:
>>
>> > --
>> > --  Besides the Ada.Command_Line you can just use functions for
>> > --  the instead of procedures for your nain program. This design is
>> > --  great for application where Command_Line is not used.
>> > --
>>
>> > function work return Integer is
>>
>> >   begin
>> >     return ( 0 ) ; -- no error status code
>> >   end work ;
>>
>> Be aware that this is not portable. The only main subprogram that all
>> compilers must support (if they support a main subprogram) is "public
>> parameterless library procedures" (RM2005 10.2, 29 - previous RMs have
>> similar requirements), i.e.
>>
>>    procedure Main is
>>    ...
>>
>> Cheers
>> -- Martin
>
>
>Right; and even if your Ada compiler *does* support functions that
>return integers as main programs, and you're compiling for some
>operating system with an "x" in its name (or Solaris), this does *not*
>mean that the Ada compiler will treat the function result as the
>status code.  The compiler could decide that the function result is
>something to be formatted and spit out onto standard output.  If an
>Ada implementation supports parameters and/or function results on main
>programs, the language leaves it up to the implementation how those
>are interpreted.  There's no rule that says that the interpretation
>has to mimic the behavior of the C language (thank God).  So anon's
>solution may work on GNAT, but it can't be assumed to work anywhere
>else.
>
>                                -- Adam

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

[Adam Beneschan]

On May 5, 1:48 pm, a...@anon.org (anon) wrote:
> Actually, Adam the design for all OS currectly use today states that if the
> program returns the "Accumulator Register" will contain the program exit
> code. Been a standard for at least 40 years.

Define "the program".

"The program" that is run by the OS is not necessarily the Ada main
subprogram.  In fact, it probably won't be.  An Ada subprogram used as
the main program isn't going to have all the library package
elaboration or finalization code run by the Ada environment task (RM
10.2), since it is compiled separately, and at the time it's compiled
the Ada compiler won't necessarily know that it's going to be the main
program.  Therefore, the "program" is probably going to be some sort
of wrapper that calls the initialization code, calls the main
subprogram, then calls the finalization code.  There's no standard
anywhere that says that this wrapper must preserve the value that the
Ada main subprogram sticks in the accumulator register (or wherever
function results are stored).  [P.S. Note that the environment task is
a *task* and has no return value, in Ada semantics, for what it's
worth.]

So your comment isn't particularly relevant.  It certainly doesn't
prove anything.

                                -- Adam

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

[Hibou57 (Yannick Duchêne)]

On 5 mai, 22:48, a...@anon.org (anon) wrote:
> Actually, Adam the design for all OS currectly use today states that if the
> program returns the "Accumulator Register" will contain the program exit
> code. Been a standard for at least 40 years.
>

Not sure,

The DOS interrupt 21h function 0h, which ends *.COM program (does not
apply to *.EXE due to the PSP allocation logic), set the AH register
to zero and does not interpret AL : no exit code in the accumulator
AX.

The DOS interrupt 21h function 31h (TSR : terminate and stay resident)
for *.COM and *.EXE, and interrupt 21h function 4Ch (terminate and
free program instance) both expect the AH register set with the
function code (31h or 4Ch) and the exit code in AL. The accumulator is
splitted with a function code in the high byte and an exit code in the
low byte : the accumulator AX does not represent an exit code (only
the low byte).

Note : this reply is just for fun :P

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

[anon]

Martin.

  You misread RM 10.2 (29), its quoted below.

Both of the subprograms types are valid and portable and even though 
RM 10.2 (29) allows a vendor to restrict the main subprogram. Adacore 
(GNAT) and IBM which follow the RM to the letter have decided to allow 
and support both main subprograms types in Ada 83/95/2005 specs.

Note: At this time Adacore and IBM are the only ones supporting Ada 2005.

Now, in the GNAT design the "GNATBIND" process actually wraps the main 
subprogram ( "procedure main" or a "function main return integer" ) within 
a function called "main" within a package called "ada_main".  And if the 
"main" subprogram is a procedure, the binder function "main" calls this 
procedure and returns the exit status which is normally set to zero unless it 
is altered by "Ada.Command_Line.Set_Exit_Status". But if main subprogram 
is a function type of partition, then the binder function "main" returns the 
value returned from the partition "function main" to the OS as the exit 
status. To see this, just compile any program and then bind it. Check the 
resulting output files "b~<name>.adb" and its spec file before linking. 

Note: normally during linking the linker "GNATLINK" deletes the 
binder source/object files.


So both of these are valid in the RM.  It just that most programmers prefer 
the "Procedure" type of partitions design.

--
-- main subprograms as a procedure 
--
procedure main is
  begin -- main
     null ;
  end main ;
--
-- or main subprograms as a public parameterless function
--
function main return integer is
  begin -- main
     return ( 0 ) ; -- 0 := normal exit status.
  end main ;



Ada RM -- quoted 


  RM 10.2 Program Execution
   ...

                         Implementation Permissions
   ...

29    An implementation may restrict the kinds of subprograms it supports as
                        ------------
main subprograms. However, an implementation is required to support all main
                                                            ----------------
subprograms that are public parameterless library procedures.
-----------


  RM 10.1 Separate Compilation


1     A program unit is either a package, a task unit, a protected unit, a
protected entry, a generic unit, or an explicitly declared subprogram other
                                       ------------------------------
than an enumeration literal. Certain kinds of program units can be separately
compiled. Alternatively, they can appear physically nested within other
program units.



In <8ef6052e-4f51-416b-bae7-ff83d7024267@t11g2000vbc.googlegroups.com>, Martin <martin.dowie@btopenworld.com> writes:
>On May 4, 5:09=A0pm, a...@anon.org (anon) wrote:
>> --
>> -- =A0Besides the Ada.Command_Line you can just use functions for
>> -- =A0the instead of procedures for your nain program. This design is
>> -- =A0great for application where Command_Line is not used.
>> --
>>
>> function work return Integer is
>>
>> =A0 begin
>> =A0 =A0 return ( 0 ) ; -- no error status code
>> =A0 end work ;
>
>Be aware that this is not portable. The only main subprogram that all
>compilers must support (if they support a main subprogram) is "public
>parameterless library procedures" (RM2005 10.2, 29 - previous RMs have
>similar requirements), i.e.
>
>   procedure Main is
>   ...
>
>Cheers
>-- Martin

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

[Martin]

On May 5, 9:31 pm, a...@anon.org (anon) wrote:
> Martin.
>
>   You misread RM 10.2 (29), its quoted below.
>
> Both of the subprograms types are valid and portable and even though
> RM 10.2 (29) allows a vendor to restrict the main subprogram. Adacore
> (GNAT) and IBM which follow the RM to the letter have decided to allow
> and support both main subprograms types in Ada 83/95/2005 specs.
>
> Note: At this time Adacore and IBM are the only ones supporting Ada 2005.
>
> Now, in the GNAT design the "GNATBIND" process actually wraps the main
> subprogram ( "procedure main" or a "function main return integer" ) within
> a function called "main" within a package called "ada_main".  And if the
> "main" subprogram is a procedure, the binder function "main" calls this
> procedure and returns the exit status which is normally set to zero unless it
> is altered by "Ada.Command_Line.Set_Exit_Status". But if main subprogram
> is a function type of partition, then the binder function "main" returns the
> value returned from the partition "function main" to the OS as the exit
> status. To see this, just compile any program and then bind it. Check the
> resulting output files "b~<name>.adb" and its spec file before linking.
>
> Note: normally during linking the linker "GNATLINK" deletes the
> binder source/object files.
>
> So both of these are valid in the RM.  It just that most programmers prefer
> the "Procedure" type of partitions design.
>
> --
> -- main subprograms as a procedure
> --
> procedure main is
>   begin -- main
>      null ;
>   end main ;
> --
> -- or main subprograms as a public parameterless function
> --
> function main return integer is
>   begin -- main
>      return ( 0 ) ; -- 0 := normal exit status.
>   end main ;
>
> Ada RM -- quoted
>
>   RM 10.2 Program Execution
>    ...
>
>                          Implementation Permissions
>    ...
>
> 29    An implementation may restrict the kinds of subprograms it supports as
>                         ------------
> main subprograms. However, an implementation is required to support all main
>                                                             ----------------
> subprograms that are public parameterless library procedures.
> -----------
>
>   RM 10.1 Separate Compilation
>
> 1     A program unit is either a package, a task unit, a protected unit, a
> protected entry, a generic unit, or an explicitly declared subprogram other
>                                        ------------------------------
> than an enumeration literal. Certain kinds of program units can be separately
> compiled. Alternatively, they can appear physically nested within other
> program units.


You forgot to underline the important bit - "procedures". Not
"subprograms", not "functions or procedures" - just "procedures". The
_only_ subprogram that _must_ be supported is:

   procedure <Main_Subprogram_Name> is
   ...

Yes an implementation is free to support other forms (including
functions) but they are not portable.

Lord only know why your quoting 10.1 - it's nothing to do with main
procedures.

Cheers
-- Martin

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

[anon]

By your logic, who said procedures are portable!  Using RM 10.2 (29), a 
vendor could easily restrict the "main subprograms" to functions only. 
And there is no definition in the RM that states a "main subprograms" 
subroutine must be a parameterless library procedure, either.

So, its better to have and state that both subprogram types are portable. Then 
one can point out that the "main subprograms" that are procedures are more 
widely used in Ada. 


In <948d6a6b-d603-4e38-add2-50016c2dcc9d@s20g2000vbp.googlegroups.com>, Martin <martin.dowie@btopenworld.com> writes:
>On May 5, 9:31=A0pm, a...@anon.org (anon) wrote:
>> Martin.
>>
>> =A0 You misread RM 10.2 (29), its quoted below.
>>
>> Both of the subprograms types are valid and portable and even though
>> RM 10.2 (29) allows a vendor to restrict the main subprogram. Adacore
>> (GNAT) and IBM which follow the RM to the letter have decided to allow
>> and support both main subprograms types in Ada 83/95/2005 specs.
>>
>> Note: At this time Adacore and IBM are the only ones supporting Ada 2005.
>>
>> Now, in the GNAT design the "GNATBIND" process actually wraps the main
>> subprogram ( "procedure main" or a "function main return integer" ) withi=
>n
>> a function called "main" within a package called "ada_main". =A0And if th=
>e
>> "main" subprogram is a procedure, the binder function "main" calls this
>> procedure and returns the exit status which is normally set to zero unles=
>s it
>> is altered by "Ada.Command_Line.Set_Exit_Status". But if main subprogram
>> is a function type of partition, then the binder function "main" returns =
>the
>> value returned from the partition "function main" to the OS as the exit
>> status. To see this, just compile any program and then bind it. Check the
>> resulting output files "b~<name>.adb" and its spec file before linking.
>>
>> Note: normally during linking the linker "GNATLINK" deletes the
>> binder source/object files.
>>
>> So both of these are valid in the RM. =A0It just that most programmers pr=
>efer
>> the "Procedure" type of partitions design.
>>
>> --
>> -- main subprograms as a procedure
>> --
>> procedure main is
>> =A0 begin -- main
>> =A0 =A0 =A0null ;
>> =A0 end main ;
>> --
>> -- or main subprograms as a public parameterless function
>> --
>> function main return integer is
>> =A0 begin -- main
>> =A0 =A0 =A0return ( 0 ) ; -- 0 :=3D normal exit status.
>> =A0 end main ;
>>
>> Ada RM -- quoted
>>
>> =A0 RM 10.2 Program Execution
>> =A0 =A0...
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Implementation Permiss=
>ions
>> =A0 =A0...
>>
>> 29 =A0 =A0An implementation may restrict the kinds of subprograms it supp=
>orts as
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ------------
>> main subprograms. However, an implementation is required to support all m=
>ain
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ----------------
>> subprograms that are public parameterless library procedures.
>> -----------
>>
>> =A0 RM 10.1 Separate Compilation
>>
>> 1 =A0 =A0 A program unit is either a package, a task unit, a protected un=
>it, a
>> protected entry, a generic unit, or an explicitly declared subprogram oth=
>er
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
>=A0 =A0------------------------------
>> than an enumeration literal. Certain kinds of program units can be separa=
>tely
>> compiled. Alternatively, they can appear physically nested within other
>> program units.
>
>
>You forgot to underline the important bit - "procedures". Not
>"subprograms", not "functions or procedures" - just "procedures". The
>_only_ subprogram that _must_ be supported is:
>
>   procedure <Main_Subprogram_Name> is
>   ...
>
>Yes an implementation is free to support other forms (including
>functions) but they are not portable.
>
>Lord only know why your quoting 10.1 - it's nothing to do with main
>procedures.
>
>Cheers
>-- Martin

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

[Martin]

On May 6, 9:41 am, a...@anon.org (anon) wrote:
> By your logic, who said procedures are portable!

Perhaps you could rephrase that into a meaning sentence?


>  Using RM 10.2 (29), a
> vendor could easily restrict the "main subprograms" to functions only.

No they can't - read the sentence begining "However". In fact, here it
is:

  "However, an implementation is required to support all main
   subprograms that are public parameterless library procedures."

Read it slowly. Read it repeatedly.

Here's a link to it:

http://www.adaic.org/standards/1zrm/html/RM-10-2.html


> And there is no definition in the RM that states a "main subprograms"
> subroutine must be a parameterless library procedure, either.

See above. Especially the link.


> So, its better to have and state that both subprogram types are portable. Then
> one can point out that the "main subprograms" that are procedures are more
> widely used in Ada.

That's would be lying, so probably better not to state this at all.



> In <948d6a6b-d603-4e38-add2-50016c2dc...@s20g2000vbp.googlegroups.com>, Martin <martin.do...@btopenworld.com> writes:
>
> >On May 5, 9:31=A0pm, a...@anon.org (anon) wrote:
> >> Martin.
>
> >> =A0 You misread RM 10.2 (29), its quoted below.
>
> >> Both of the subprograms types are valid and portable and even though
> >> RM 10.2 (29) allows a vendor to restrict the main subprogram. Adacore
> >> (GNAT) and IBM which follow the RM to the letter have decided to allow
> >> and support both main subprograms types in Ada 83/95/2005 specs.
>
> >> Note: At this time Adacore and IBM are the only ones supporting Ada 2005.
>
> >> Now, in the GNAT design the "GNATBIND" process actually wraps the main
> >> subprogram ( "procedure main" or a "function main return integer" ) withi=
> >n
> >> a function called "main" within a package called "ada_main". =A0And if th=
> >e
> >> "main" subprogram is a procedure, the binder function "main" calls this
> >> procedure and returns the exit status which is normally set to zero unles=
> >s it
> >> is altered by "Ada.Command_Line.Set_Exit_Status". But if main subprogram
> >> is a function type of partition, then the binder function "main" returns =
> >the
> >> value returned from the partition "function main" to the OS as the exit
> >> status. To see this, just compile any program and then bind it. Check the
> >> resulting output files "b~<name>.adb" and its spec file before linking.
>
> >> Note: normally during linking the linker "GNATLINK" deletes the
> >> binder source/object files.
>
> >> So both of these are valid in the RM. =A0It just that most programmers pr=
> >efer
> >> the "Procedure" type of partitions design.
>
> >> --
> >> -- main subprograms as a procedure
> >> --
> >> procedure main is
> >> =A0 begin -- main
> >> =A0 =A0 =A0null ;
> >> =A0 end main ;
> >> --
> >> -- or main subprograms as a public parameterless function
> >> --
> >> function main return integer is
> >> =A0 begin -- main
> >> =A0 =A0 =A0return ( 0 ) ; -- 0 :=3D normal exit status.
> >> =A0 end main ;
>
> >> Ada RM -- quoted
>
> >> =A0 RM 10.2 Program Execution
> >> =A0 =A0...
>
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Implementation Permiss=
> >ions
> >> =A0 =A0...
>
> >> 29 =A0 =A0An implementation may restrict the kinds of subprograms it supp=
> >orts as
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ------------
> >> main subprograms. However, an implementation is required to support all m=
> >ain
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ----------------
> >> subprograms that are public parameterless library procedures.
> >> -----------
>
> >> =A0 RM 10.1 Separate Compilation
>
> >> 1 =A0 =A0 A program unit is either a package, a task unit, a protected un=
> >it, a
> >> protected entry, a generic unit, or an explicitly declared subprogram oth=
> >er
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
> >=A0 =A0------------------------------
> >> than an enumeration literal. Certain kinds of program units can be separa=
> >tely
> >> compiled. Alternatively, they can appear physically nested within other
> >> program units.
>
> >You forgot to underline the important bit - "procedures". Not
> >"subprograms", not "functions or procedures" - just "procedures". The
> >_only_ subprogram that _must_ be supported is:
>
> >   procedure <Main_Subprogram_Name> is
> >   ...
>
> >Yes an implementation is free to support other forms (including
> >functions) but they are not portable.
>
> >Lord only know why your quoting 10.1 - it's nothing to do with main
> >procedures.

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

[Georg Bauhaus]

Martin schrieb:
> On May 6, 9:41 am, a...@anon.org (anon) wrote:
>> By your logic, who said procedures are portable!
> 
> Perhaps you could rephrase that into a meaning sentence?
> 
> 
>>  Using RM 10.2 (29), a
>> vendor could easily restrict the "main subprograms" to functions only.
> 
> No they can't - read the sentence begining "However". In fact, here it
> is:
> 
>   "However, an implementation is required to support all main
>    subprograms that are public parameterless library procedures."

Indeed, and why would anyone want to use compiler hacks when
there is a prefectly well documented standard solution
involving exit codes?

A competition with C programmers? Like, "I, an Ada programmer,
can play the same tricks, in Ada, as you can in C, no hassle
at all?  I'm just as clever as you are because, me too,
can rely on compiler docs and platform conventions
for dealing with int as return codes?" Goodness.

What is wrong with the standard, if naturally implementation-defined,
Exit_Status that *guarantees* the OS will be able to deal with
it?
Doing otherwise (i.e. trying to use a function instead)
might force rewriting the function as a main procedure
and call Set_Exit_Status when switching compilers.
So what is the point?

Use Ada, even when your compiler is GNAT.