Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!sri-unix!ctnews!pyramid!uccba!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: Non repeatable behaviour on Vax 4.2bsd [was: Re: non repeatable, 4.3 C compiler behavior] Message-ID: <3631@ncoast.UUCP> Date: Sun, 26-Jul-87 15:58:48 EDT Article-I.D.: ncoast.3631 Posted: Sun Jul 26 15:58:48 1987 Date-Received: Wed, 29-Jul-87 04:27:59 EDT References: <328@rocksanne.UUCP> <567@yabbie.oz> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 24 As quoted from <567@yabbie.oz> by rcodi@yabbie.oz (Ian Donaldson): +--------------- | There is nothing worse than trying to debug a piece of software | that *sometimes fails* when given the same input in successive runs. | Any system that doesn't initialize core on process start falls | into this category. +--------------- I agree with the first sentence. But anyone who depends on a variable being 0 on program start-up gets what he deserves on an OS that doesn't zero memory or registers. What happens if a variable's zero value isn't a binary zero? (Example: FP on some machines.) Also, the next step is to zero auto variables on function start-up; this strikes me as ridiculous unnecessary overhead. I *always* explicitly initialize variables. This avoids any potential problems with OSes that don't do it for me, or non-binary-zero representations of zero values, etc. It's _safer_. -- Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <>