[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Writing libraries for C programs using Guile Scheme

From: Mateusz Kowalczyk
Subject: Re: Writing libraries for C programs using Guile Scheme
Date: Fri, 07 Mar 2014 16:30:33 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 07/03/14 08:22, Peter TB Brett wrote:
> Hi all,
> Recently, there have been some really horrible programming errors found in
> widely-used and security-critical libraries (GnuTLS, for example).
> These libraries are usually written in C because C is a "lowest common
> denominator": if a library is written in C, almost every language will be
> able to access its functions somehow (for example, in Guile we can use the
> dynamic FFI).
> I've now realised that it would be *really awesome* to be able to write
> some code in Scheme, and automatically generate a .so file (or DLL) and a C
> header file that I could then easily (and safely) use in other programs
> without any special handling (including via Guile's FFI).  I think it would
> be much easier to avoid some of these recent stupid "goto fail;" bugs if we
> were writing in Scheme.

I doubt that going from a single inherently unsafe but bloody fast
language to slightly less unsafe but much slower language is an
advantage here…

> It seems to me that most of the things needed for this are already in
> place, although at some performance cost and probably some restrictions in
> the sort of programs that can be written in this way:
> - Guile can already pack bytecode into ELF object files.
> - Andy Wingo has demonstrated generation of simple native code from Guile
> (compost!).
> - libguile provides the infrastructure needed to load and run Guile
> bytecode, and we can get the dynamic linker to pull it in.
> So what's needed?  I've had a few ideas for how this could work. Each
> function exported by the library needs to have a native code stub in the
> ELF .text section, which:
> a. Puts the thread into Guile mode
> b. Marshals the corresponding Scheme function
> c. Deals with uncaught exceptions - probably with SIGABRT.
> d. Asserts that the return value from the Scheme function is a pure foreign
> type
> e. Leaves Guile mode
> f. Returns
> Unfortunately I'm sure that I've missed some important bits (for example,
> thread safety & reentrancy), and I *certainly* don't have enough low-level
> Guile knowledge to make this work.  So I'd be very interested to hear what
> people think about this idea.
> Best wishes,
> Peter

Do you feel like you can provide correctness proofs for your
implementations of such security critical libraries? Scheme isn't
exactly the safest language.

Mateusz K.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]