Re: Problem upgrading c4gl to 7.20 (variable initialisation)

Jonathan Leffler wrote: > > On Mon, 19 Oct 1998, Robert Cowham wrote: > > > We are recompiling an app with c4gl 7.20.UD2 and it appears to behave > > differently to 6.05.UD1 in that unitialised variables are set to true whereas > > previously they were set to false. > > GLOBAL variables and module (file static) variables are initialized to all > zeroes; that's typically 0 or null. Otherwise, uninitialized local > variables have whatever random garbage was left over from whatever > previously used the same space. That might coincidentally have been zeroes > previously and now is different, but that's why you don't rely on > uninitialized variables -- you can't predict what their value will be. > > These rules should not have changed. > > Now, if your problem is with GLOBAL variables or module variables, say so, > and you may yet have cause for complaint. > > If your problem is with local variables -- which, in my experience, is > usually where this problem rears its ugly head -- then your code is faulty > and that's pretty much the end of the issue. The behaviour was undefined > and is still undefined and it is unfortunate that it used to work correctly > and now doesn't, but the problem is still in your code, not in the product > per se. 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? 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 Perhaps the type name first as in C has some merit? ;-) > > > This has some implications for our code surprise, surprise. Has anyone else > > come across this? > > > > Any suggestions as to an easy work around (apart from fixing the code...) such > > as a compiler switch setting or whatever? > > No; the only real workaround is to fix the code. > > 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 -- Peter Lancashire Information Systems Specialist, Bayer plc Eastern Way, Bury St Edmunds, Suffolk, IP32 7AH, UK Tel: +44-1635-562258, Fax: +44-1635-562281 --- If all else fails, read the instructions and the release notes. Join Infuse, the UK Informix User Group at http://www.infuse.org.uk/ ---