Do you cheat with GLOBALS?
Posted in 1994
Hi, Do you cheat with GLOBALS? Background ---------- I4GL translates the code on the left into, more or less, the C on the right (Sequence A): filea.4gl filea.c ========= ======= GLOBALS a DATETIME YEAR TO SECOND, dtime_t a; b CHAR(20), char b[21]; c DECIMAL dec_t c; END GLOBALS MAIN main() { END MAIN } fileb.4gl fileb.c ========= ======= GLOBALS a DATETIME YEAR TO SECOND, dtime_t a; b CHAR(20), char b[21]; c DECIMAL dec_t c; END GLOBALS FUNCTION f() f() { END FUNCTION } When you link filea.o and fileb.o together, this strictly leads to doubly defined variables, as filea.c and fileb.c both define the variables a, b, and c. However, the vast majority of C compilers actually allow this doubly definition, as long as at most one of the definitions includes an initializer. This means that you normally get away with it. What you're supposed to do, of course, is define a file which contains the GLOBALS definitions, and then use that file where you need to refer to those GLOBALS, like this (Sequence B): fileg.4gl fileg.c ========= ======= GLOBALS a DATETIME YEAR TO SECOND, dtime_t a; b CHAR(20), char b[21]; c DECIMAL dec_t c; END GLOBALS filea.4gl filea.c ========= ======= GLOBALS "fileg.4gl" extern dtime_t a; extern char b[21]; extern dec_t c; MAIN main() { END MAIN } fileb.4gl fileb.c ========= ======= GLOBALS "fileg.4gl" extern dtime_t a; extern char b[21]; extern dec_t c; FUNCTION f() f() { END FUNCTION } Now when you link filea.o, fileb.o and fileg.o, there are no doubly defined variables to cause any C compiler any problems. So much for the theory. What's behind this? The problem I face is that the new 6.00 ESQL/C compiler will generate initializers for for both filea.c and fileb.c in Sequence A when the variables contain DATETIME or INTERVAL types. Further, it is correct to do so, and it ensures that the rest of the file behaves correctly. However, code written in the style of Sequence A no longer links, with doubly defined symbols. In this example, a would be doubly defined, because the definitions in both filea.c and fileb.c would contain initializers. Question -------- Do you make use of the short-cut which can lead to doubly defined symbols? If so, how much? Answers please to me by email. Thank you for your cooperation. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>