linux-kernel - Re: Official Linux system wrapper library?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Nov 2018 10:13:08 -0800
From:   Paul Eggert <eggert@...ucla.edu>
To:     Joseph Myers <joseph@...esourcery.com>,
        Andy Lutomirski <luto@...capital.net>
Cc:     Szabolcs Nagy <Szabolcs.Nagy@....com>,
        Dave P Martin <Dave.Martin@....com>,
        Daniel Colascione <dancol@...gle.com>, nd <nd@....com>,
        Florian Weimer <fweimer@...hat.com>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Joel Fernandes <joelaf@...gle.com>,
        Linux API <linux-api@...r.kernel.org>,
        Willy Tarreau <w@....eu>, Vlastimil Babka <vbabka@...e.cz>,
        Carlos O'Donell <carlos@...hat.com>,
        "libc-alpha@...rceware.org" <libc-alpha@...rceware.org>
Subject: Re: Official Linux system wrapper library?

On 11/14/18 9:40 AM, Joseph Myers wrote:
> Historically, there was once an attempt to rework POSIX into a separate
> language-independent definition and language bindings (for C, Fortran, Ada
> etc.), but I don't think it got anywhere, and it's probably doubtful
> whether the idea was ever very practical.

That effort did produce IEEE Std 1003.5-1992 (Ada Bindings to IEEE Std 
1003.1-1990), IEEE 1003.5b-1996 (Ada bindings for realtime extensions), 
and IEEE Std 1003.9-1992 (F77 Bindings to IEEE Std 1003.1-1992). The Ada 
group simply translated the POSIX standard from C into Ada, repeating 
functional text and coming up with a "thick" standard; in contrast the 
Fortran group did a "thin" standard that focused on Fortran mechanics 
and deferred underlying functionality to the main POSIX standard. The 
thin Fortran standard was harder to grok and was less successful in 
practice.

As you write, these efforts were probably not worth the trouble. Non-C 
language systems can provide a standard way to invoke C APIs, and then 
let user-level programmers have at it. The performance advantage of 
having a pure Ada/Fortran/etc. API for POSIX are so minor that it's not 
worth the major hassle of standardizing and using a language-independent 
POSIX API.