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

[anon@anon.org (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
>
>
>