As an arbitrary design decision, extensions can read the values of
built-in variables and arrays (such as
FS), but cannot
change them, with the exception of
The reason for this is to prevent an extension function from affecting
the flow of an awk program outside its control. While a real
awk function can do what it likes, that is at the discretion
of the programmer. An extension function should provide a service or
make a C API available for use within awk, and not mess with
In addition, it becomes easy to start down a slippery slope. How
much access to gawk facilities do extensions need?
Do they need
getline? What about calling
compiling regular expressions? What about calling into awk
functions? (That would be messy.)
In order to avoid these issues, the gawk developers chose to start with the simplest, most basic features that are still truly useful.
Another decision is that although gawk provides nice things like MPFR, and arrays indexed internally by integers, these features are not being brought out to the API in order to keep things simple and close to traditional awk semantics. (In fact, arrays indexed internally by integers are so transparent that they aren't even documented!)
Additionally, all functions in the API check that their pointer
input parameters are not
NULL. If they are, they return an error.
(It is a good idea for extension code to verify that
pointers received from gawk are not
Such a thing should not happen, but the gawk developers
are only human, and they have been known to occasionally make
With time, the API will undoubtedly evolve; the gawk developers expect this to be driven by user needs. For now, the current API seems to provide a minimal yet powerful set of features for creating extensions.