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
<>