Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!husc6!panda!enmasse!comm!dave
From: dave@comm.UUCP (Dave Brownell)
Newsgroups: net.micro.mac
Subject: Re: >64k code segs. WAS: Aztec C assembler bug?
Message-ID: <267@comm.UUCP>
Date: Sun, 1-Jun-86 15:49:03 EDT
Article-I.D.: comm.267
Posted: Sun Jun  1 15:49:03 1986
Date-Received: Tue, 3-Jun-86 23:56:31 EDT
References: <2852@utcsri.UUCP> <759@jade.BERKELEY.EDU> <761@jade.BERKELEY.EDU>
Reply-To: dave@comm.UUCP (Dave Brownell)
Organization: EnMasse Computer Corp, Acton, MA
Lines: 22

In article <761@jade.BERKELEY.EDU> oster@ucblapis.UUCP,
otherwise known as "David Phillip Oster" writes:

> [ Much prose omitted ]

> 2.) resolve the calling graph against the linker source file to discover
> what calling chains might potentially cause problems due to heap shuffling
> and un-locked pointers.

    Maybe I'm being naive ... but this is exactly the class of bugs
    that I like to fix by not making them in the first place.  Is it
    really THAT hard to obey the discipline of locking your handles
    when you pass "hard pointers" around?  Or of fixing someone else's
    code to do that?  (Or not using "hard pointers" hardly ever?)

    I think a good top-down design in the first place can eliminate
    maybe 50% of the debugging cycle, and will give a better product
    in the end.  (As well as giving a nice clean calling graph!!)
-- 
Dave Brownell		{panda,genrad,harvard}!enmasse!comm!dave

"They sang long into the evening about their Truck and Radio."