Article View: comp.sys.atari.st
Article #24512RE: Malloc() Flame
From: LINDAHL
Date: Fri, 23 Jan 1987 08:54
Date: Fri, 23 Jan 1987 08:54
46 lines
3018 bytes
3018 bytes
Date: Fri, 23 Jan 87 00:50 EST
From: <LINDAHL@BRANDEIS.BITNET>
Subject: RE: Malloc() Flame
To: info-atari16@score.stanford.edu
X-Original-To: info-atari16@score.stanford.edu, LINDAHL
In digest 87-35, imagen!atari!apratt@ucbvax.Berkeley.EDU (Allan Pratt) writes:
> PLEASE don't go around publishing internal addresses like this requests,
> since such addresses are GUARANTEED to change and BREAK programs which
> count on them. Some parts of an operating system are hidden from
> view ON PURPOSE, so the OS can be sure that its data structures will
> not be fooled with by user programs.
>
> The correct procedure in this kind of situation is to say, "Gee, Atari,
> I lose memory over time.. I wonder if there's a problem in the memory
> allocator? Here is an example program which demonstrates the problem..."
Calm down, Allan. I am not planning on running out and distributing programs
which depend upon internal addresses, and then flame you when my programs
break! Rather, I intend to examine this problem very thoroughly. If I told
you, "well, I think that sort of, you know, I lose some memory sometimes
after running one of the myriad versions of micro-emacs and maybe at other
times with some combinations of a bunch of programs," then you would ignore
me. You would ignore me for good reason, because I haven't provided enough
information to find the bug.
My intent is to explore the problem, and see if I can find a good example.
If I can, you'll be the first to know. If I can come up with a fix, and you
guys can't/won't fix it, then I _might_ consider distributing a fix with
breakable code. But it _would_ be documented as such.
Finally, please do not assume that anyone is a moron who needs to have
these weighty "operating systems issues" explained to him. Undoubtedly 99.9%
of the programmers listening to this conversation realize the folly of
using internal addresses in publicly-distributed programs.
Greg Lindahl
brandeis radio astronomy group (BRAG)
bitnet: lindahl@brandeis us snail: box 2522 brandeis university
ci$: [76515,1122] waltham mass (usa) 02254-9110
(617) 899-5884
[NSA CIA Cray hackey-sack tie-dye divestment radical civil disobedience
Thoreau Locke Hobbes flower-power frisbee physics star wars Teller
long hair vegetarians 'and to think that MY tax dollars pay for this!']
Technical Details
Message-ID:
<8701231451.AA10776@ucbvax.Berkeley.EDU>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!brandeis.BITNET!LINDAHLShow Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!brandeis.BITNET!LINDAHL From: LINDAHL@brandeis.BITNET Newsgroups: comp.sys.atari.st Subject: RE: Malloc() Flame Message-ID: <8701231451.AA10776@ucbvax.Berkeley.EDU> Date: Fri, 23-Jan-87 03:54:33 EST Article-I.D.: ucbvax.8701231451.AA10776 Posted: Fri Jan 23 03:54:33 1987 Date-Received: Sat, 24-Jan-87 00:12:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: LINDAHL%BRANDEIS.BITNET@forsythe.stanford.edu Organization: The ARPA Internet Lines: 46