Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!styx!ames!ucbcad!ucbvax!decvax!tektronix!tekgen!tekigm!tekigm2!phils From: phils@tekigm2.UUCP Newsgroups: comp.sys.amiga Subject: Re: AmigaDOS: How to know if a file is on RAM: Message-ID: <1474@tekigm2.TEK.COM> Date: Thu, 12-Feb-87 13:49:41 EST Article-I.D.: tekigm2.1474 Posted: Thu Feb 12 13:49:41 1987 Date-Received: Sat, 14-Feb-87 23:09:00 EST References: <157@batcomputer.tn.cornell.edu> Reply-To: phils@tekigm2.UUCP (Philip E Staub) Organization: Tektronix, Inc., Beaverton, OR. Lines: 47 Keywords: AmigaDOS, RAM:, Lock(), ParentDir(). In article <157@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes: .... ><--- Extra! Second question for the price of one! ---> > Just off-hand, does anyone know if a "lock" as returned >from Lock() is either (a) a plain old "long", or (b) is really >and truly a pointer to a FileLock struct. In my code, if I assume >its a long, all is cool. But if I assume its a FileLock, and try >to tweak the FileLock->fl_Volume field, I get a free visit from my >significant other (eg the guru). This leads me to believe that >Lock() is just returning a long (maybe the sector on the disk?) >but I would not mind independent verification. > >-- Dan Green Pardon me for shot-gunning this, but I don't have my manuals handy. Sounds to me like you're using the Manx compiler in 16 bit int mode, and not declaring that Lock() returns a pointer to a FileLock struct as: struct FileLock *Lock(); or including the 'functions.h' include file. If you don't declare the return type of a routine to be something other than an int, the compiler assumes it is indeed an int, and (on a 16 bit compiler) only uses the least significant 16 bits of the return value. But any pointer is 32 bits. Hence any pointer over 0xffff is truncated, which certainly cause a guru. (I speak from experience here 8-) ). I have pretty much universally decided to include the 'functions.h' file in any program I write, and this has eased the 16 vs. 32 bit int situation greatly. The only other major gotcha I run into otherwise is ensuring that parameters (n.b.: don't forget constants) passed to routines expecting 32 bit parameters (which includes most of the standard library functions) are cast as longs. Finally, I found out (the hard way) while playing with the sample printer drivers in the RKM that the Lattice compiler always seems to pass 32 bit parameters, even if the parameter type is declared as 'char' or 'short'. The Manx compiler assumes that parameters which are declared as 'char' or 'short' only take up 2 bytes on the stack. Well, enough of that. Hope it helps. -- ------------------------------------------------------------------------------- Phil Staub tektronix!tekigm!phils (206) 253-5634 Tektronix, Inc., ISI Engineering P.O.Box 3500, M/S C1-904, Vancouver, Washington 98668