Code Generation Conventions

External Variables

External identifiers differ from ordinary identifiers in one important respect: IBM 370 link utilities treat upper- and lowercase letters as if they were the same. Therefore, when default options are used, the compiler converts all external identifiers to uppercase. For example, although the programmer may consider vermont and VERMONT to be two different functions, the linkage editor does not. If they are intended to be distinct functions, the compiler extname option should be used. (See The extname option.)

External names are limited by the 370 object code format to eight characters, and SAS/C translates underscores ( _ ) in external names to pound signs ( # ). Since the compiler always assumes that external names have the same characteristics as ordinary identifiers, programmers must be careful not to define external names that the compiler believes are different but that the linkage editor interprets as the same name.

A safe rule is to use lowercase letters only for all items that are declared external or that have no storage class and are positioned outside functions. These items include functions and data items that are to be defined for reference from functions in other source files. Avoid using the dollar sign ($) as the eighth character of a function name since this may cause it to duplicate the name of a control section generated by the compiler for some other function.

You can define external objects with any name that does not begin with a dollar sign ( $ ), two underscores (__) or an underscore followed by a letter. Certain library functions and data elements (defined in modules written in C) have names that start with an underscore (that appears as a pound sign ( # ) in the object code) or a dollar sign ( $ ).

The extname option

To circumvent the above restrictions, the compiler enables you to specify the extname option, which permits extended names of up to 64K in length. An extended name is any name that identifies an extern variable or that identifies an extern or static function and fits either of the following criteria:

is longer than eight characters
is at most eight characters long, contains uppercase alphabetic characters, and is not the name of an __asm or high-level language (for example, __pascal ) function.

External Variable Models

The compiler uses one of two reference-definition (ref/def) models for external variables, depending upon whether reentrant modification of external variables is allowed. The rent and rentext compiler options are used as follows to determine whether or not reentrant code is generated:

If norent is specified, reentrant execution is not allowed and the compiler uses the strict ref/def model.
If rent is specified, reentrant modification is allowed and the compiler uses the common ref/def model, unless the refdef compiler option is also specified. (The refdef option forces the use of the strict ref/def model.)

See Reentrant and Non-reentrant Identifiers for more information about rent and norent .

Common ref/def model

The common model allows any number of definitions (including 0), with and without initializers, and any number of declarations of an external variable to be present. A single declaration is sufficient to create the variable. Only one definition of an external variable may specify an initializer. If more than one is encountered, the COOL linkage editor preprocessor issues a warning message, and the actual initial values used are unpredictable. If no initializations of a variable are present, then the variable is initialized to 0 as the C language definition requires.

Strict ref/def model

In contrast to the common model, the strict ref/def model requires exactly one definition, with or without an initializer, to be present for each external variable. Again, if no initializations of a variable are present, then the variable is initialized to 0.

Programming Considerations

Any program that conforms to the strict ref/def model also conforms to the common model. However, the reverse is not true. A program that takes advantage of the common model (for example, by omitting definitions for some variables) may not compile or link correctly when using the strict ref/def model. Also, a program that uses the common model and is compiled with the rent or rentext option may not work correctly when compiled with the norent option.

The ISO/ANSI C Standard mandates the strict ref/def model for external variables. If you plan to move a program to other machines, follow the strict ref/def model unless you are sure that all the other C compilers follow a more permissive model.

You should not link compilations that have been created with the rent and rentext options with compilations that have been created with the norent option. External variables cannot be shared between these two types of compilations, nor will the resulting load module be reentrant.

Object code produced by the compiler with the rent or rentext options must be preprocessed by COOL if external variables are initialized in more than one compilation. Conversely, object code produced by the compiler with the norent option does not need to be preprocessed by COOL. If you use the rent option rather than the rentext option, the initializations of static as well as external variables affect whether or not the use of COOL is required.

Chapter Contents
Previous
Next
Top of Page