Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!gwyn@BRL.ARPA From: gwyn@BRL.ARPA (VLD/VMB) Newsgroups: net.lang.c Subject: Re: Global ptrs init to NULL or 0000? Message-ID: <3239@brl-tgr.ARPA> Date: Fri, 15-Nov-85 01:43:03 EST Article-I.D.: brl-tgr.3239 Posted: Fri Nov 15 01:43:03 1985 Date-Received: Sat, 16-Nov-85 09:49:09 EST Sender: news@brl-tgr.ARPA Lines: 31 I don't see much problem with the requirement that any defined statically-allocated storage that has no explicit initializer be initialized as though the constant 0 were assigned to it. (This phrasing ensures that such pointers will start out with the correct representation for null pointers (not necessarily a zero bit pattern)). As I am sure you are aware, a vast quantity of existing C code assumes that such data is implicitly initialized to "zero" (not necessarily with the same interpretation as X3J11), so your example of int big_array[32767]; would have to be initialized to zero somehow in any reasonable existing implementation of C. The UNIX .bss trick works only for a limited set of architectures anyhow; if "zero" means a non-zero bit pattern, the compiler or linker is going to have to use an approach other than auto-zeroing of .bss upon process startup. I believe your point was that there may be overhead caused by this initialization, even in the case that the auto-init-to-zero values are not going to be used because the code is going to store into the array before referencing it. I agree that it would be much cleaner to declare that defined data that is not explicitly initialized may not be referenced until after something has been explicitly stored into it. I follow this practice in my own code (not counting modifications to existing software that does not follow these rules). But that would clearly "invalidate" much existing code that has (reasonably) been considered correct up to now.