Re: 4GL Debugger with global variables used by C code

>From: Daniel Wright <dw420@airmail.net> >Date: Mon, 14 Jul 1997 22:09:05 -0500 >X-Informix-List-Id: <news.40410> > >We have a program which is compiled from a 4GL source module and a C >module. There is a global variable declared as "extern" in the C's header >file, as well as being declared in the GLOBALS of the 4GL. This compiles >and runs fine as far as that is concerned, BUT when using the debugger, we >are forced to compile a standalone executable (the debugger program), >which then uses the 4gi file containing the 4GL code. I'm not clear what you're using. It sounds as if you are using both the c-code compiler and the p-code compiler (and debugger). >Problem 1: We get unresolved symbol errors, since the variable is declared >externally. The c-code compilation will work OK since all the variables become C variables. The p-code compilation will work, but will fail at run-time since the p-code system does not allow access to external C variables, and C code cannot access the p-code global variables either. All the variables declared using I4GL must be defined using I4GL with the p-code system. >Solution to Problem 1: Declare the variable within the C code. This >appears to work fine when compiling the entire thing, since apparently >the 4GL compiler is "smart" enough to check for previous declarations >when parsing the GLOBALS statement. Umm. What it does is simply declares the variables in a GLOBALS statement as 'extern'. As long as some file defines the variable, all is OK. Your C compiler (linker) may treat the extern declaration as a tentative (common) definition, which may mean you don't have to formally define it. However, depending on that is prone to problems when you port to another machine. >However, when running this through the debugger, we have apparently >created 2 separate variables (one local to the C module and the other >local to the 4GL.) This was "proven" by the fact that after calling >the C function in the debugger, the "global" variable was still NULL, >while inserting display statements in the usual executable showed that >the variable actually contained what was expected. Correct; the p-code variables are disjoint from the c-code variables, with the notable exception of those which the debugger (and p-code runner) take pains to make available to both systems -- those variables are INT_FLAG, QUIT_FLAG, STATUS, SQLCA (and I think that's it!). >(Unacceptable) solution to problem created by "Solution to Problem 1": >Run the program with display (or other logging) after each call to a C >function, and then use the LET statement in the debugger to make the 4GL >"pseudo-global" variable act as if it were really global. Ouch. But I guess it will work. >Is there a better solution? (Besides the obvious "avoid global >variables" I'd rather not rewrite the entire program). I'm not sure that there is a better solution. The p-code system does not provide you with the access you need, so you are very close to stuck. >Did my description make sense? I'll be glad to elaborate if need be. >This happened with Informix 7.21 running on HP-UX 10.0. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> PS: I decline to respond to messages with anti-spam in the return path.