Path: utzoo!attcan!uunet!cbmvax!rutgers!ucsd!ucbvax!CLOUD9.BERKELEY.EDU!dillon
From: dillon@CLOUD9.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: BCPL pointers
Message-ID: <8812162011.AA02295@cloud9.berkeley.edu>
Date: 16 Dec 88 20:11:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 45

steelie@pro-charlotte.cts.com (Jim Howard) Writes:
:Is there any quick and easy way to find a 68000 address from
:a BCPL filehandle, such as the one returned by the 
:_LVOOpen  dos.library call?   I need to do some relative
:offsets and data copying directly into the file, and I
:can't really do it without this... The main reason I need
:to use it is for something like, 
: 
:Open file1
:Open file2
: 
:read 50 bytes from file1 into file2 using the _LVOWrite
:function, by giving the routine the address of file1
:instead of a "buffer" ... 
: 
:any help appreciated!
:/s

	It can't be done.  You have a file handle returned from some
Open() call.  This is a BCPL pointer to a file handle.  You shift
it left 2 to get a real pointer to a file handle structure.

	Which contains various fields of which only two are really
used.  One points to the handler process, and the other, fh_Arg1, is a 
'private data pointer' that is that handler's notion of a handle on the 
file.  I.E. a RAM: disk might use this field to point to a memory structure.
A filesystem handler might use this field to point to a sector on the disk.

	What this 'private data pointer' points to is not documented and
can't be documented because it is in the domain of the implementation of
that particular handler.  The fh_Buf and other associated fields in the 
file handle structure ARE NOT USED BY THE FILESYSTEM.  These are BCPL 
cludges for the DOS superstructure (argument passing to BCPL programs, 
etc...).  The only time the actual device driver has access to the file 
handle structure is in the packets associated with an Open() call.  
After that, the handler knows only about fh_Arg1.

				----

	Now, beyond that there is the fact that the filesystem probably
won't read the data into any internal buffers at all until you issue
the Read() call so even if you were to hack your way in to find where
its internal buffers are (a no-no in itself), the data would not be there.

						-Matt