Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!oliveb!sun!cmcmanis
From: cmcmanis@sun.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Lock and FileLock
Message-ID: <17615@sun.uucp>
Date: Wed, 29-Apr-87 13:59:52 EDT
Article-I.D.: sun.17615
Posted: Wed Apr 29 13:59:52 1987
Date-Received: Fri, 1-May-87 02:05:34 EDT
References: <6640@allegra.UUCP>
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 31
Summary: Because they are BPTR's

In article <6640@allegra.UUCP>, dsf@allegra.UUCP (David Fox) writes:
> In the include files supplied by Manx, functions such as Lock, DupLock,
> CurrentDir are declared as returning pointers to struct Lock.  However,
> there is no struct Lock defined in the include files.  Instead, most of
> the documentation (ALL of the documentation) casts the result of these
> functions to struct FileLock.  Furthermore, when I try to look at the
> field fd_Task of a lock, my system crashes.  Can anyone explain this to
> me?
> David Fox
> P.S.  By look at, I mean that if I execute the statement
> task = lock->fl_Task, my system crashes.

The Manx declarations are wrong. The Lock calls return a BCPL Pointer
(commonly referred to as a BPTR) to a FileLock structure. To make this
into a real or absolute pointer you need to shift it left by 2 bits
(multiply it by 4). There is a macro in <exec/dos.h> called BADDR that
does this for you. So to get the task above you would have to use
the syntax :

	task = (struct FileLock *)(BADDR(lock))->fl_Task;

Fortunately all of the Lock calls use BPTR's so they are self consistent.
When ever you are using DOS oriented calls, like Lock beware the BCPL 
influence. This is where it is most prevalent.


-- 
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These views are my own and no one elses. They could be yours too, just
call MrgCop() and then ReThinkDisplay()!