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
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, …
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.
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.
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. 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.
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
Besides dyncall and dyncallback, the dynload library needs to be extended with support for other shared library formats (e.g. AmigaOS .library or GEM  ﬁles).