Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!rochester!bbn!uwmcsd1!marque!uunet!mcvax!ukc!dcl-cs!bath63!pes
From: pes@bath63.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: null fill eliminated
Message-ID: <2657@bath63.ux63.bath.ac.uk>
Date: 8 Jun 88 15:35:53 GMT
References: <490@philmds.UUCP> <1067@atari.UUCP>
Reply-To: pes@ux63.bath.ac.uk (Smee)
Organization: AUCC c/o University of Bath
Lines: 19

In article <1067@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>This is appalling! Please get over the idea that you can fool with stuff
>in ROM.  For starters, some programs EXPECT that the whole heap (not
>just the declared BSS) is zeroed at startup...  Microsoft Write is one. 

I may be coming close to starting a theological argument here.  On the other
hand, I spent ages, some years ago, in helping users convert IBM/360
applications (where storage was zeroed when you got it) to run on IBM/370
systems (where it wasn't -- or was it the other way round?).  Anyway,
I was always taught, and since that experience have believed, that you
should **NEVER** write a program which depends upon ANYTHING being ANYWHERE
in storage, unless it put it there itself -- with the obvious exception, of
course, of DEFINED system locations.

So, what I find appalling is that a company like Microsoft (who I generally
think highly of) would hire programmers who indulge in writing code that
relies on this sort of undocumented effect.  If Microsoft Write (or anything
else) WANTS an alloc'ed block of storage to contain zeroes, it oughta D**N
WELL put them there its-own-self.  Period.