Re: Problem upgrading c4gl to 7.20 (variable initialisation)

On Tue, 20 Oct 1998, Peter Lancashire wrote: > Jonathan Leffler wrote: > > [...] Otherwise, uninitialized local > > variables have whatever random garbage was left over from whatever > > previously used the same space. [...] > > > > I sometimes think we should have introduced a scheme whereby > > random values were copied into local variables deliberately to ensure that > > they were initialized correctly by the user, especially in p-code where the > > variables are actually set on entry to the function (which leads to the > > biggest problems when code is ported from p-code to c-code). > > Might another solution have been to change the language to force the > programmer to initialise the variable when defining it? Force wasn't an option -- backwards compatability. Some systems (notably SunOS/Solaris) seem to bend over backwards to zero previously unused stack. Since there's a function call at the start of each I4GL function now (that helps eliminate the TSS overflow and error -4518), that function now scribbles over the previously clean stack, leading to bigger problems. This misguided zeroing on Solaris has caused endless problems, even within Informix when code that seemed to work on Solaris didn't work on other machines. The Sun environment is too damn friendly sometimes. There's an interesting discussion on some other news group (maybe comp.software.config-mgmt) about giving the developers the older, less capable machines so that what works fast enough for them will work even better on the actual users more recent, more powerful machines. I have at least some sympathy for that viewpoint. > It seems a little kinder to me. > Syntax might go: > > DEFINE myvar smallint = 4 > > or, kinder to the user but less so to the compiler writer: > > DEFINE myvar = 4 smallint That would be a possibility. > Perhaps the type name first as in C has some merit? ;-) Yes. All sorts of things might be possible. But the basic problem of uninitialized variables is the same -- the value is not reliably predictable, even though it may have seemed to be predictable with some previous version of the o/s, C compiler or I4GL compiler. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn