Conference decwet::nt-developers

3231.0. "global variable usage in VC++" by HYDRA::LNARAYAN () Wed Apr 30 1997 12:46

    Hello
    
    This problem is reported by a partner, I have also tested this using 
    VC++ 4.0 and Alpha NT V4.0 to find that the TLS global variable value 
    is lost when using it from a function. Any suggestions? or Is this a
    known problem?
    
    Thanks In Advance
    Lakshminarayan
    
    
    PS: cross posted in DECWET::VISUAL
    ============================================================================
    sample code

Description: Global TLS variables on DEC Alpha NT do not behave the same as
on Intel Alpha NT. If the global TLS variable was defined twice in two
different files and linked with the /FORCE:MULTIPLE option, NT/VC++ on
DEC Alpha AXP treats it as a new variable while NT/VC++ on Intel platform
treats it as the same variable. This difference seems to exist only on tls
variables and not on other type of variables. Please see the simple example
with the output below:

/* main.c file */
#include <stdio.h>
#include <windows.h>
#include <winbase.h>

void sub();

__declspec(thread) HANDLE hfile = NULL; /*Global tls variable definition */
int x = 123; /* Global variable x */

main()
{
   char name[5] = "abc";
   hfile = CreateFile(
                      (LPCTSTR) name, 
                      GENERIC_READ | GENERIC_WRITE,
                      FILE_SHARE_READ | FILE_SHARE_WRITE, 
                      NULL, 
                      OPEN_ALWAYS,
                      FILE_ATTRIBUTE_NORMAL,
                      NULL
                      );
                      
   printf("I am in main: \n");
   printf("Handle created was : h = %d\n",hfile);
   printf("X should be 123    : x = %d\n",x);
   printf("===========================");
   sub();
}

----------------------------

/* sub.c file */ 
#include <stdio.h>
#include <windows.h>
#include <winbase.h>

__declspec(thread) HANDLE hfile; /* duplicate definition */
int x;                           /* already defined in main.c */

void sub()
{
printf("\nNow I am in sub routine: \n");
printf("Handle should be the same: h = %d\n",hfile);
printf("X should be still be 123:  x  = %d\n",x);
}

-----------------------------------------
OUTPUT on Alpha AXP NT:

D:\test>main
I am in main:
Handle created was : h = 76
X should be 123    : x = 123

Now I am in sub routine:
Handle should be the same: h = 0
X should be still be 123:  x  = 123

OUTPUT on Intel NT:

D:\test>
I am in main: 
Handle created was : h = 80
X should be 123    : x = 123

Now I am in sub routine: 
Handle should be the same: h = 80
X should be still be 123:  x  = 123

As you can see above, the handle created, h =76, in main was not visible in
the sub routine for DEC Alpha NT. The printf shows the handle to be 0 when
it should be 76.

======================================================
This is how it was compiled and linked:

E:\test>cl -c main.c sub.c
Microsoft (R) & Digital (TM) Alpha C
Copyright (C) Microsoft Corp 1984-19
Copyright (C) Digital Equipment Corp
All rights reserved.

main.c
sub.c
Generating Code...

E:\test>link /FORCE:MULTIPLE main.obj sub.obj
Microsoft (R) 32-Bit Incremental Linker Version 4.20.6164
Copyright (C) Microsoft Corp 1992-1996. All rights reserved.

sub.obj : warning LNK4006: _hfile already defined in main.obj; second
definition ignored
main.exe : warning LNK4088: image being generated due to /FORCE option;
image may not run

E:\test>

================================================================================
    
     
                  
    

  RE: -1

  I tested the program on VC50 (RTM, V11.01.7050) and linker v5.01.7044,
  the problem was non reproducible.


C:\miller\vcxx>main
I am in main:
Handle created was : h = 76
X should be 123    : x = 123

Now I am in sub routine:
Handle should be the same: h = 76
X should be still be 123:  x  = 123

I got same warning messages at link time though:

sub.obj : warning LNK4006: _hfile already defined in main.obj; second
definition ignored
main.exe : warning LNK4088: image being generated due to /FORCE option;
image may not run


  I will verify if the problem is indeed reproducible on our VC4.2b system
  tomorrow.  If it is, there is two way we can fix this:
       1. ask ISV to upgrade to VC50
  or   2. provide a vc4.2b patch

  Which one is likely to happen? 

  
  Miller