DLL Programmer's Guide for TNS/E Systems

Finding Symbol Definitions
DLL Programmer’s Guide for TNS/E Systems—527252-006
4-4
Global Scope, Import and Export
and libraries). Furthermore, the application of these concepts differs from one source
language to another.
In the C language, items declared within a function are local to that function and are
undefined (invisible) elsewhere. Items declared outside any function have global scope
and are visible in any function that does not hide that declaration with a local one of the
same name. (In languages with nested functions, such as Pascal, there are multiple
levels of nested scopes. In pTAL, a SUBPROC has a scope nested within that of the
PROC.)
The C language defines storage class (sometimes also called linkage); the two storage
classes that apply to global functions and data are extern and static. Global data
and functions with static linkage are visible to the functions within this compilation
unit, but are local to the compilation, and therefore to the linkfile that results from the
compilation. Global variables with no specified storage class are implicitly extern.
The explicit specification of extern linkage on an uninitialized variable declares the
variable but leaves it undefined; if there are references in this compilation, they must
be linked to a definition in another.
(The pTAL language has no explicit storage class. Everything is effectively extern
except SUBPROCs, which are static.)
When the linker combines multiple linkfiles to build a loadfile, global extern definitions
in one linkfile are available to satisfy references to an undefined symbol in another;
these items are considered global in the resulting loadfile. However, static global items
within each linkfile become local in the loadfile.
A key part of the linker's job is binding global references in one linkfile to definitions in
another. For C compilation units, the linker enforces the language requirement that a
given symbol have at most one definition in the loadfile. For some constructs common
in header files, the C++ language generates definitions in every compilation that
includes the header; the compiler marks these symbols to inform the linker that
multiple definitions are acceptable, and the linker is expected to bind all references to
one of them. Slightly different rules apply to some pTAL definitions, such as data
blocks: the linker will accept multiple definitions, as long as any initialized data is the
same in each.
If none of the linkfiles contributing to a loadfile defines a referenced symbol, it remains
undefined in the loadfile. In this case, it will need to be bound to a definition in some
other loadfile. In such a case, the referencing file is said to import the symbol, and the
defining loadfile is said to export it. In a DLL with globalized import control, it is also
possible for a symbol to be imported even though that symbol is of
fered for export; in
this case the definition in this DLL is said to be preempted by a definition in a loadfile
appearing earlier in the program's loadList.
Only some of the global symbols in the loadfiles can be shared with other loadfiles:
those that are offered for export, and those that are undefined (require import). There
are several ways that symbols become available for export. By default, the linker offers
for export only symbols that the compiler designates as exportable. With the C/C++
compilers, you can specify export or import of individual symbols, or of whole classes.