Q38725: Why Unitialized Global Variables Don’t Appear in C 5.10
Article: Q38725 Product(s): See article Version(s): 3.65 Operating System(s): MS-DOS Keyword(s): ENDUSER | SR# G881021-5044 | mspl13_basic Last Modified: 6-DEC-1988 Questions: Why don't uninitialized global variables show up in the library listing when the module containing them has been placed in the library? It appears that the librarian does not "see" uninitialized global variables. If my main program declares an extern, and an .OBJ with which its linked declares it globally (without extern), but doesn't initialize it, the symbol appears in the link map and space is allocated for it in the .EXE. This behavior seems different from previous versions of the compiler. If the .OBJ file is placed as a library rather than linked explicitly, the symbol does not appear in the .EXE. Why does it behave differently? Response: In Version 5.00 of the C Compiler, we introduced a new concept into our linking process called "communal data." Communal data can be declared in many modules, but only one copy of the data will exist in the linked .EXE file. (It is similar to the concept of COMMON blocks in FORTRAN.) In C, data declared outside of a function without a storage class is now considered to be communal data. (This is a change from previous versions.) Communal data declarations generate no definitions, just declarations; whereas initialized, or global, data declarations generate both definitions and declarations. Communal declarations may refer to a global definition. If they do, the linker simply adjusts the address as necessary. However, if there is no global definition of the variable, the linker combines the declarations into one definition and allocates the appropriate amount of space. For example, it is legal to declare int x; in several different modules without a corresponding int x = 0; Communal declarations are NOT copied into libraries. (This is documented on Page 84 of the "Microsoft C Language Reference Manual.") If you want the variable to appear in a library, it MUST be initialized so that it is global rather than communal. Communal variables are not included in libraries because they can cause strange conflicts. For example, let's suppose you unwittingly used a variable name that was also the name of a communal variable in your library. At link time, the linker would allocate only ONE copy of that variable without generating any warning. The symptom would be that your variable would mysteriously change every time you called the library function that used the communal variable. This problem would be a very difficult to trace. Now that we understand communal variables and how they interact with libraries, we can answer your questions. The first question was basically, "Why don't my communal variables show up in the library listing?" Because communal data is not placed into the library, it won't show up in the listing. The second question was, "How come the communal variable shows up in the .EXE file if I link it from an .OBJ file but not from a .LIB file?" It shows up from the .OBJ file because the communal variable is allocated space by the linker if it doesn't resolve to a global definition. It does NOT appear in the link produced by the .LIB file because it does not appear in the library dictionary. Note: this behavior is the result of doing something we ask you not to do; namely, putting communal data in a library. Data intended to be placed in a library must be initialized.
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1986-2002.