Uninitialized externals and statics.

Fred Smith fredex at cg-atla.UUCP
Thu Aug 24 03:35:48 AEST 1989


In article <783 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) writes:
>In article <1786 at crdgw1.crd.ge.com> davidsen at 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 at uk.ac.ed             
>AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed at 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.)



More information about the Comp.lang.c mailing list