Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!cg-atla!fredex From: fredex@cg-atla.UUCP (Fred Smith) Newsgroups: comp.lang.c Subject: Re: Uninitialized externals and statics. Message-ID: <7550@cg-atla.UUCP> Date: 23 Aug 89 17:35:48 GMT References: <2128@infmx.UUCP> <10764@smoke.BRL.MIL> <478.nlhp3@oracle.nl> <1989Aug19.053711.7462@twwells.com> <1786@crdgw1.crd.ge.com> <783@skye.ed.ac.uk> Reply-To: fredex@cg-atla.UUCP (Fred Smith) Organization: Agfa Compugraphic Division Lines: 40 In article <783@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >In article <1786@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >> Although the proposed ANSI standard (3.5.7 line 20) calls for >>initialization to zero, cast to the appropriate type (my paraphrase) for >>arithmetic and pointer types, virtually all implementations initialize >>to zero (without cast) in the absense of explicit initialization. > >Are there any well-known machines on which these aren't equivalent, and >on which the "wrong" initialization is done? > >-- Richard > > >-- >Richard Tobin, JANET: R.Tobin@uk.ac.ed >AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk >Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin On a Prime 50-series machine the representation of a NULL pointer is not all zeroes! As far as I know, however, this does not cause a problem in such initializations. It is appropriate when testing a pointer against for being the null pointer to do a case, thusly: char * foo; if (foo == (char *)NULL) but then doing such a cast is ALWAYS appropriate, on any machine, since right after you leave the company somebody will get the bright idea of porting your code to some new whiz-bang-100 processor with weird architecture. This is also apprpriate on 8086-class machines, since the representation of a pointer, including the null pointer, will vary with memory model. (I hate segmented architectures.)