gawk and an extension is two-way. First, when an extension
gawk passes it a pointer to a
struct whose fields are
This is shown in Figure 17.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 functions.
This is shown in Figure 17.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 17.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 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 extension filefuncs.c (see Example: Some File Functions) and also in the testext.c code for testing the APIs.
Some other bits and pieces:
do_xxxvalues, reflecting command-line options, like
do_profiling, and so on (see 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 API Version Constants and Variables for details.