United States |
|
|
||
5.4.5.2 #pragma extern_model common_blockThis pragma sets the compiler's model of external data to the common block model, which is the one used by VAX C. The #pragma extern_model common_block directive has the following format:
In this model, every declaration of an object with the extern storage class causes a global overlaid psect to be created. Both ANSI C definition declarations and reference declarations create the same object file records. The psect has the same name as the object itself. There is no global symbol in addition to the psect name. The object file records generated are the same as those generated by VAX C for extern objects.
See Section 4.8 for a description of how definitions using each
external model are interpreted, what psect they would reside in, and
what psect attributes are assigned. Also note the effect of the
const
type specifier for these definitions.
This pragma sets the compiler's model of external data to the relaxed ref/def model, which is the one used by pcc on UNIX systems. The #pragma extern_model relaxed_refdef directive has the following format:
Be aware that an attr keyword of gbl or lcl is not allowed on the relaxed_refdef model. With this model, three different types of object-file records can be produced, depending on the declaration of the object:
See Section 4.8 for a description of how definitions using each
external model are interpreted, what psect they would reside in, and
what psect attributes are assigned. Also note the effect of the
const
type specifier for these definitions.
This pragma is the preferred alternative to the nonstandard storage-class keywords globaldef and globalref . This pragma sets the compiler's model of external data to the strict ref/def model. Use this model for a program that is to be an ANSI C strictly conforming program. The #pragma extern_model strict_refdef directive has the following formats:
The name in quotes, if specified, is the name of the psect for any definitions. Note that attr keywords cannot be specified for the strict_refdef model unless a name is given for the psect. This model provides two different cases:
See Section 4.8 for a description of how definitions using each external model are interpreted, what psect they would reside in, and what psect attributes are assigned. Also note the effect of the const type specifier for these definitions.
5.4.5.5 #pragma extern_model globalvalueThis pragma sets the compiler's external model to the globalvalue model, and is the preferred alternative to the nonstandard storage-class keyword globalvalue . This pragma has the following format:
Notice that this model does not accept attr keywords. This model provides two different cases:
5.4.5.6 #pragma extern_model saveThis pragma pushes the current external model of the compiler onto a stack. The stack records all information associated with the external model, including the shr / noshr state and any quoted psect name. This pragma has the following format:
The number of entries allowed in the
#pragma extern_model
stack is limited only by the amount of memory available to the compiler.
This pragma pops the external model stack of the compiler. The external model is set to the state popped off the stack. The stack records all information associated with the external model, including the shr / noshr state and any quoted psect name. This pragma has the following format:
On an attempt to pop an empty stack, a warning message is issued and
the compiler's external model is not changed.
Using different Compaq C external models can introduce mutually incompatible object files. An object file compiled with one extern model may not link against an object file compiled with a different model. Table 5-1 compares what happens when a reference or definition in an object file compiled with one external model is linked against a reference or definition in an object file compiled with a different external model. Note that the table is symmetric about the diagonal. For example, to look up what happens when you mix a relaxed_refdef reference with a strict_refdef definition, you can locate either the relaxed_refdef reference row and the strict_refdef definition column or the relaxed_refdef reference column and the strict_refdef definition row. Table 5-1 contains no entries for mixing globalvalue symbols with other external models because globalvalue symbols are used only in special cases; they are not used as a general-purpose external model. For the other external models, there is a row and column for every different case. The common_block model only has one case because all symbols are definitions in that model; the relaxed_refdef model has three cases because it distinguishes between references, uninitialized definitions, and initialized definitions.
Notes ref means reference; def means definition. In the common_block model, all external symbols are considered to be defs. A ref works with a ref if they both refer to the same thing. A def works with a ref if the def fulfills the ref. A def works with a def if they are combined into one by the linker. Multi means that the linker issues a multiply defined symbol error. This indicates a user error, not a mismatch between external models. As Table 5-1 shows, the common_block model mixes poorly with the strict_refdef model, but the relaxed_refdef model works well with the common_block model and the strict_refdef model. The relaxed_refdef model fails only when a relaxed_refdef reference is linked against a common_block definition. The fact that the external models are not all compatible with each other can be an issue for providers of general-purpose object libraries. One goal for such a library should be to work when linked with client code compiled with any of the external models. Otherwise, the provider of the object library might be forced to provide one copy of the library compiled with /EXTERN_MODEL=COMMON_BLOCK, another compiled with /EXTERN_MODEL=STRICT_REFDEF, and another compiled with /EXTERN_MODEL=RELAXED_REFDEF to let anyone link with the library. The best way to accomplish the goal of allowing an object library to be linked with any code regardless of the external model used is to provide header files that describe the interface to the object library. The header files can declare the global variables used by the object library after using #pragma extern_model to set the external model to the one used by the library. Programmers who want to use the library could then include these header files to get the required declarations. In order to avoid altering the external model used by the including program, header files should start with a #pragma extern_model save directive and end with a #pragma extern_model restore directive. The Compaq C RTL uses this approach.
If header files are not provided, an object library should use the
relaxed_refdef
external model since it will link successfully with either
common_block
compiled code or
strict_refdef
compiled code. The only restriction is that the library must not
reference an external symbol that is not defined in the library but is
defined only in the user program. This avoids the
common_block
case that fails. Note that the
relaxed_refdef
model allows both the library and the user code to contain definitions
for any symbol, as long as both do not attempt to initialize the symbol.
Example 5-1 shows the use of #pragma extern_model in a sample module. Assume that the module is compiled with the /EXTERN_MODEL=COMMON and /SHARE_GLOBALS qualifiers.
Key to Example 5-1:
5.4.6 #pragma extern_prefix DirectiveThe #pragma extern_prefix directive controls the compiler's synthesis of external names, which the linker uses to resolve external name requests. When you specify #pragma extern_prefix with a string argument, the compiler attaches the string to the beginning of all external names produced by the declarations that follow the pragma specification. This pragma is useful for creating libraries where the facility code can be attached to the external names in the library. The #pragma extern_prefix directive has the following format:
The quoted "string" is attached to external names in the declarations that follow the pragma specification. You can also specify an extern prefix for specific identifiers using the optional list [(id[,id]...)]. The nocrtl and restore_crtl keywords control whether or not the compiler applies its default RTL prefixing to the names specified in the id-list, which is required for this form of the pragma. The effect of nocrtl is like that of the EXCEPT=keyword of the /PREFIX_LIBRARY_ENTRIES command-line qualifier. The effect of restore_crtl is to undo the effect of a #pragma extern_prefix NOCRTL or a /PREFIX=EXCEPT= on the command line. The save and restore keywords can be used to save the current pragma prefix string and to restore the previously saved pragma prefix string, respectively. The default external prefix, when none has been specified by a pragma, is the null string. The recommended use is as follows: #pragma extern_prefix save When an extern_prefix is in effect and you are using #include to include header files, but do not want the extern_prefix to apply to extern declarations in the header files, use the following code sequence: #pragma extern_prefix save Otherwise, external prefix is attached to the beginning of external identifiers for definitions in the included files. All external names prefixed with a nonnull string using #pragma extern_prefix are converted to uppercase letters regardless of the setting of the /NAMES qualifier.
| |
privacy statement and legal notices |