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-Thread: a07f3367d7,d8e3cd3d8dbaa4fb X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.75.8 with SMTP id y8mr1288518wiv.4.1343313020146; Thu, 26 Jul 2012 07:30:20 -0700 (PDT) Path: ge7ni75568486wib.0!nntp.google.com!feed-C.news.volia.net!volia.net!news2.volia.net!feed-A.news.volia.net!border1.nntp.ams2.giganews.com!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!newsfeed.straub-nv.de!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Ada "library only" compiler ? Date: Sat, 21 Jul 2012 00:51:47 +0200 Organization: A noiseless patient Spider Message-ID: <87mx2ucags.fsf@ludovic-brenta.org> References: <2879c45e-f8e0-4434-9f82-968c585a4539@googlegroups.com> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="3e923ec8967cff61065e8d85ac343f1e"; logging-data="6482"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WOiDUi/UHHO4JMd3Ql5bo" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Cancel-Lock: sha1:gB8VbwFjJ6vmtqYk9mxtftr+kUQ= sha1:eAP2UyXLNwmWT6BFC2DXiyrFi9g= Content-Type: text/plain; charset=us-ascii Date: 2012-07-21T00:51:47+02:00 List-Id: Peter C. Chapin writes on comp.lang.ada: > On 2012-07-20 17:11, Niklas Holsti wrote: > >> GNAT runs on operating systems (Windows, Linux, etc.) in which the >> Application Programming Interface is defined in C. In order to open a >> file under Linux, the application (here GNAT) *must* use the open() >> or fopen() functions, which are defined in the API as C >> functions. Trying to open a file using "low-level Ada" would be >> breaking the OS interface which is obviously a bad idea (and probably >> impossible because an application does not have the necessary >> low-level access rights for that). > > I don't think this is quite right. Entrance into the operating system > is ultimately done in machine language. The C API functions you're > talking about are thin wrappers that present a C callable interface > and then do what must be done to actually invoke the system. For some > systems "doing what must be done" involves executing exotic > instructions that (standard) C compilers can't generate. Thus one > supposes that functions like open(), etc, are written in assembly > language or its moral equivalent. Just two days ago I spent some time browsing the sources of glibc to discover how the stat(2) C library call translates to a _stat64 kernel call then converts the 64-bit result back to 32-bit, explicitly detects overflows, sets ERRNO and returns a status code (0=success, -1=error). This alone involves several dozen lines of C, interspersed with dozens of #define, #ifdef and #endif. glibc must work at least with Linux, kFreeBSD and HURD. This increases its complexity and would likewise increase the complexity of a raw Ada-to-kernel interface. Add to this that glibc has maintained strict binary compatibility since January 1997, resorting to more magic ("symbol versioning") that most anyone would care to learn about. Achieving the same thing in Ada would require a careful definition of "semantic dependence" such that recompiling the kernel-interface library does not systematically invalidate all compilation units that depend on it, per ARM 10.1.4(5). IOW, magic at the source level in addition to the binary level. So the conclusion is: while it is theoretically possible to write an Ada run-time library that interfaces directly with the kernel, it is practically undesirable. The huge effort required would bring almost no benefit and should be spent elsewhere. For the same reason, Florist (the free implementation of POSIX.3) uses C wrappers and the C library. -- Ludovic Brenta.