Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!husc7!hadeishi
From: hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi)
Newsgroups: comp.sys.amiga
Subject: chdir() bug in Lattice (Manx, too?)
Message-ID: <1720@husc6.UUCP>
Date: Wed, 22-Apr-87 02:33:08 EST
Article-I.D.: husc6.1720
Posted: Wed Apr 22 02:33:08 1987
Date-Received: Thu, 23-Apr-87 05:15:52 EST
Sender: news@husc6.UUCP
Reply-To: hadeishi@husc7.UUCP (Mitsuharu Hadeishi)
Organization: Harvard Univ. Science Center
Lines: 28
Summary: chdir() doesn't unlock new file system lock


	I've just spent some time tracking down a 24-byte memory leak
in SlideShow 1.2.  What I realized is that the Lattice chdir() must
be doing something like the following:

	CurrentDir(Lock(pathname,ACCESS_READ));

	The problem with this is that the lock obtained from Lock() takes
up 24 bytes and is never freed.  That is, every time I ran my program
I lost 24 bytes, until I replaced chdir() with

	newdir = Lock(pathname,ACCESS_READ);
	olddir = CurrentDir(newdir);

	and later, on exit:

	CurrentDir(olddir);
	UnLock(newdir);

	Now I can't see how one can implement chdir() to be UNIX-
compatible unless you also add some bookkeeping code to keep track
of when chdir() is invoked and what file system locks it is obtaining,
and on exit() UnLock those locks.  Ideally, you should only have to
unlock one lock, since a succession of chdir() calls should automatically
UnLock() the old directory lock if it was obtained from a previous
chdir() Lock() call.

					-Mitsu