dyncall Manual

Stability and security considerations

Since the dyncall library doesn’t know anything about the called function itself (except its address), no parameter-type validation is done. This means that in order to avoid crashes, data corruption, etc., the user is required to ascertain the number and types of parameters. It is strongly advised to double check the parameter types of every function to be called, and not to call unknown functions at all.

Consider a simple program that issues a call by directly passing some unchecked command line arguments to the call itself, or even worse, by indirectly choosing a library to load and a function to call without veriﬁcation. Such unchecked input data can quite easily be used to intentionally crash the program or to take over control of the program ﬂow.
If not used with care, programs depending on the dyncall, dyncallback and dynload libraries, can be exploited as arbitrary function call dispatchers through manipulation of their input data. Successful exploits of badly formed programs like outlined above can be misused as powerful tools for a wide variety of malicious attacks, …

Embedding

The dyncall library strives to have a minimal set of dependencies, meaning no required runtime dependencies and usually only the necessary tools to build the library as build-time dependencies, like a compiler and assembler, linker, etc.. The library uses some heap-memory to store the CallVM and uses by default the platform’s malloc() and free() calls. However, providing custom dcAllocMem and dcFreeMem C-preprocessor deﬁnitions will override the default behaviour. See dyncall/dyncall_alloc.h for details.

Multi-threading

The dyncall library is thread-safe and reentrant, by means that it works correctly during execution of multiple threads if, and only if there is at most a single thread pushing arguments to one CallVM. Since there’s no limitation on the number of created CallVM objects, it is recommended to keep a copy per thread if mutliple threads make use of dyncall in parallel. Invoking the call should always be thread-safe, however, whether the called function is thread-safe is up to the programmer to verify, of course.

Supported types

Currently, the dyncall library supports all of ANSI C’s integer, ﬂoating point and pointer types as function call arguments and return values. Additionally, C++’s bool and C99’s _Bool types are supported across all supported platforms. Due to the still rare and often incomplete support of the long double type on various platforms, the latter is currently not oﬃcially supported. Also, _Complex is currently not supported.

Passing or returning aggregates (struct, union) by value is supported, but only on a limited set of platforms (check if the macro DC__Feature_AggrByVal is deﬁned).

Roadmap

The dyncall library should be extended by a wide variety of other calling conventions and ported to other and more esoteric platforms. With its low memory footprint it surely comes in handy on embedded systems. Furthermore, the authors plan to provide more scripting language bindings, examples, and other projects based on dyncall.
Besides dyncall and dyncallback, the dynload library needs to be extended with support for other shared library formats (e.g. AmigaOS .library or GEM [45] ﬁles).

Related libraries

Besides the dyncall library, there are other free and open projects with similar goals. The most noteworthy libraries are libﬃ [46], C/Invoke [47] and libﬀcall [48].