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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d2df3e9ad18fa63 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-21 15:34:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!skynet.be!skynet.be!louie!tlk!not-for-mail Sender: lbrenta@lbrenta Newsgroups: comp.lang.ada Subject: Re: ISO/IEC 14519 - Ada POSIX binding References: <3EF2F6B8.3030706@noplace.com> <3EF44B79.2000407@noplace.com> From: Ludovic Brenta Date: 22 Jun 2003 00:28:48 +0200 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 80.201.75.23 X-Trace: 1056234850 reader0.news.skynet.be 313 80.201.75.23:48878 X-Complaints-To: abuse@skynet.be Xref: archiver1.google.com comp.lang.ada:39544 Date: 2003-06-22T00:28:48+02:00 List-Id: Kilgallen@SpamCop.net (Larry Kilgallen) writes: > VMS direct IP access uses the QIO system service which returns > status on every call and after every IO completion. Layering a > C-language socket structure on top of that introduces the awful > "errno" business. Now should an IP package for Ada go through that > C-language layer and try to undo the "errno" business, or should it > call the QIO system service directly and never get tied up in > "errno" at all ? The POSIX.5 Ada interface does not have to be implemented on top of the C interface, so on VMS, a well-written Ada binding would call the QIO service directly. As noted elsewhere in this thread, POSIX.5 uses an exception (Posix.Posix_Error) to report that an error occurred, and an "errno"-like variable to specify what kind of error occurred. Thanks to the exception, a lot of the ugliness goes away, and thanks to the variable, it is easier to add new error codes to POSIX.5 without breaking existing apps. > > Furthermore, I would think that anyone designing > > a new OS in the next ten years would want to make it POSIX-compliant, > > because it would be too difficult to try an impose an alternative API. > > In fact, you've probably noticed that even the MVS and z/OS mainframe > > operating systems became POSIX-compliant for just that reason. > > When VMS added Posix-compliant calls it was to allow C programmers > to use it in a fashion to which they were accustomed. They did > _not_ force all programmers to use those C conventions. Is the MVS > situation somehow more restrictive ? No, the other interfaces to the same operating system services are still available (note the plural: there are several for different languages like assembler, PL/I and Rexx). The addition of a POSIX interface just makes it easier to port applications to mainframes, which in today's world appears to be a condition for survival. -- Ludovic Brenta.