Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!gary
From: gary@mit-eddie.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: chdir() bug in Lattice (Manx, too?)
Message-ID: <5648@eddie.MIT.EDU>
Date: Wed, 29-Apr-87 12:34:54 EDT
Article-I.D.: eddie.5648
Posted: Wed Apr 29 12:34:54 1987
Date-Received: Fri, 1-May-87 01:09:39 EDT
References: <1720@husc6.UUCP>
Reply-To: gary@eddie.MIT.EDU (Gary Samad)
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 46

In article <1720@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes:
>
>	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

As long as you don't mind never being able to get back to the dir you
chdired from this will work:

	if ((templock=CurrentDir(Lock(pathname,ACCESS_READ)) != NULL)
	  UnLock(templock);

Don't forget the check for NULL!!!  You can cause latent machine crashes by
UnLocking a NULL lock!

	Gary

[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]
[restriction defeat]