From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,14aa27db81ce3b40 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!gnilink.net!wn13feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: How to exit an Ada program with (unix shell) error code? Reply-To: anon@anon.org (anon) References: <49ba30c9-a1e6-4346-8618-d256f87ac301@s31g2000vbp.googlegroups.com> <356247f9-4a83-44aa-a412-4500e6af19cf@f1g2000prb.googlegroups.com> X-Newsreader: IBM NewsReader/2 2.0 Message-ID: <2yxMl.30237$941.3661@bgtnsc04-news.ops.worldnet.att.net> Date: Thu, 07 May 2009 09:08:14 GMT NNTP-Posting-Host: 12.65.24.142 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1241687294 12.65.24.142 (Thu, 07 May 2009 09:08:14 GMT) NNTP-Posting-Date: Thu, 07 May 2009 09:08:14 GMT Organization: AT&T Worldnet Xref: g2news2.google.com comp.lang.ada:5720 Date: 2009-05-07T09:08:14+00:00 List-Id: 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 writes: >On May 5, 8:34 am, Jean-Pierre Rosen 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 > > >