1.1 Unsafety of Foreign Functions🔗ℹ

Although using the FFI requires writing no new C code, it provides relatively little insulation against the issues that C programmers face related to safety and memory management. An FFI programmer must be particularly aware of memory management issues for data that spans the Rhombus–C divide. Although the library name ffi and its exported bindings do not include the word “unsafe,” importing the library should be considered as a declaration that your code is itself unsafe, therefore can lead to serious problems in case of bugs. It is the responsibility of each library that is implemented with ffi to provide a safe interface to its clients.

The running example in this section is intended to work within DrRacket, which can display image results. Beware, however, that DrRacket runs programs in the same Racket/Rhombus process that runs DrRacket itself. A misuse of unsafe functionality can therefore crash not only the buggy program, but also DrRacket. Take appropriate care while editing, and consider falling back to command-line Racket to view error messages that might appear just before a crash.

Using the rhombus/static language (or the use_static declaration) is an especially good idea when working with foreign functions. The ffi library particularly relies on static information for pointer operations, and static mode can help avoid confusing or incorrect behavior.