dsf@allegra.UUCP (04/28/87)
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 allegra!dsf P.S. By look at, I mean that if I execute the statement task = lock->fl_Task, my system crashes.
dillon@CORY.BERKELEY.EDU.UUCP (04/29/87)
>In the include files supplied by Manx, functions such as Lock, DupLock, >CurrentDir are declared as returning pointers to struct Lock. However, >.. >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 They return pointers to a FileLock, which is a BPTR. Thus, you have to shift the address left by two before you can indirect through it to get at the structure. -Matt
cmcmanis@sun.UUCP (04/29/87)
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()!
higgin@cbmvax.UUCP (04/29/87)
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
$allegra!dsf
$
$P.S. By look at, I mean that if I execute the statement
$task = lock->fl_Task, my system crashes.
All easily explained. First, "functions.h" is WRONG in a number of ways.
It was apparently put together by support types in NJ instead of Jim
Goodnow himself (who I don't think would have made such a mistake).
Struct Lock is non-existant - it is FileLock as you said. Suggest you
fix your own functions.h (saving a copy of the original just in case!).
Also, the workbench functions clash with declarations in one of the
workbench include files (sorry, can't remember which one).
Second, your machine crashes when you try to look at a lock because
the pointer returned by one of AmigaDOS's routines is a BPTR, not
a normal address, so when you try to use it as such, you're almost
guaranteed of an addressing error (guru#3).
So try the following:
extern struct FileLock *Lock();
struct FileLock *DooDah;
DooDah = Lock("stuff", ACCESS_READ);
/*
By doing the following, the result can only be used for
examining the lock now, and cannot be passed to another
routine as a FileLock.
*/
DooDah <<= 2;
Regards,
Paul Higginbottom.ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (04/30/87)
In article <6640@allegra.UUCP> dsf@allegra.UUCP (David Fox) writes: >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 >allegra!dsf > >P.S. By look at, I mean that if I execute the statement >task = lock->fl_Task, my system crashes. Phew. Here we go again. To all self-proclaimed Amiga Gurus reading this, please let lesser-experienced Amiga programmers that you know in on this information. (In fact, someone could probably make some serious $$$ writing a book about all the "common" knowledge that isn't in the manuals.) Note: People who have heard this a million times might want to hit 'n' now. Rule #1: The DOS sucks. Rule #2: The DOS was not written in C, it was written in a language called BCPL (an acronym meaning, "British Compiler Programmers are Lousy" (q.v. Rule #1)). Because the languages are different, C's idea of a pointer is different from BCPL's idea of a pointer. Rule #3: Memory as we know it is addressed in byte-sized increments. BCPL, however, thinks memory is addressed in longword-sized increments. Therefore, a memory address in a BCPL pointer must be multiplied by the size of a longword in bytes (i.e. four) to get a real memory address. Typically, this is done in C as follows: char *c_pointer; c_pointer = (char *) ((long) bcpl_pointer << 2); The various type casts may or may not be necessary, but it makes the compiler shut up. Rule #4: All AmigaDOS functions that claim to return a pointer in fact return a BCPL pointer, commonly called a BPTR (meaning, "Braindamaged PoinTeR"). Rule #5: Only those functions covered in the AmigaDOS Developer's Manual are AmigaDOS functions. All other functions in the ROM Kernel are normal and well-behaved (e.g. GetMsg() does NOT return a BPTR (thank God)). David: This was not meant to be insulting. It's just that this has been covered many times before, and things of this nature really ought to be in the manuals in 36-point bold type. As it is, people have to ask here. Sigh. Hope this helps. Spread this information far and wide; you will help many novices this way. P.S: Sprinkle :-)'s where appropriate. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."