gawk and an extension is two-way. First, when an extension
is loaded, it is passed a pointer to a
struct whose fields are
This is shown in Figure 16.1.
The extension can call functions inside
gawk through these
function pointers, at runtime, without needing (link-time) access
gawk’s symbols. One of these function pointers is to a
function for “registering” new built-in functions.
This is shown in Figure 16.2.
In the other direction, the extension registers its new functions
gawk by passing function pointers to the functions that
provide the new feature (
do_chdir(), for example).
associates the function pointer with a name and can then call it, using a
defined calling convention.
This is shown in Figure 16.3.
do_xxx() function, in turn, then uses the function
pointers in the API
struct to do its work, such as updating
variables or arrays, printing messages, setting
ERRNO, and so on.
Convenience macros in the gawkapi.h header file make calling through the function pointers look like regular function calls so that extension code is quite readable and understandable.
Although all of this sounds somewhat complicated, the result is that extension code is quite straightforward to write and to read. You can see this in the sample extensions filefuncs.c (see Extension Example) and also the testext.c code for testing the APIs.
Some other bits and pieces:
do_xxxvalues, reflecting command line options, like
do_profilingand so on (see Extension API Variables). These are informational: an extension cannot affect their values inside
gawk. In addition, attempting to assign to them produces a compile-time error.
gawkit is loaded with supports the facilities it was compiled with. (Version mismatches “shouldn’t” happen, but we all know how that goes.) See Extension Versioning, for details.