As an arbitrary design decision, extensions can read the values of
predefined variables and arrays (such as ARGV and FS), but cannot
change them, with the exception of PROCINFO.
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
FS or ARGC and ARGV.
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 gsub() or
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 NULL.
Such a thing should not happen, but the gawk developers
are only human, and they have been known to occasionally make
mistakes.)
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.