Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: trouble opening intuition.library
Message-ID: <8811272312.AA10996@postgres.Berkeley.EDU>
Date: 27 Nov 88 23:12:33 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 41

mermelstein%tel.inrs.cdn@relay.ubc.ca (lois mermelstein) Writes:
:IntuitionBase = (struct IntuitionBase *)OpenLibrary("intuition.library",
:	INTUITION_REV);
:When the constant INUITION_REV is set to 33 or 0, I simply get "Couldn't open
:lib." from the printf.  When I set it to 33L or 0L, I get "software error --
:task held", with a guru number of "#0000000A.00C [plus some other numbers].
:
:I'm using Manx 3.6A with the default c.lib (16 bit ints) on a 2-floppy
:B2000 that's completely vanilla (nothing else running, nothing bizarre
:in the startup-sequence).

	This is a standard mistake when using 16 bit integers.  
OpenLibrary() returns a pointer, what you have above is OpenLibrary()
returning an integer and then casting it to a pointer ... which doesn't
work well since pointers are 32 bits and integers are 16 bits.  What
you want to do is DECLARE OpenLibrary() as returning a pointer:

extern char *OpenLibrary();

	I.E, *ANY* kind of pointer.  Doesn't make sense to declare it
to return a struct IntuitionBase * since OpenLibrary() does other things,
so you still need the cast as you have it but now, at least, it is
converting a pointer to another pointer rather than an int to a pointer.

:#define INTUITION_REV /*either 33, 0, 33L, or 0L */

	Same problem .. I believe Aztec expects a long, so 33L or 0L. ..
passing just an int (33, 0) would be incorrect.

	This is one of the many reasons I use +L (32 bit ints).  Everybody
says it makes for slower code and larger binaries.  I have found that the
code speed is more related to programmer experience rather than the size
of ints, and although the binaries are larger for +L they aren't *that*
much larger.  Other people say that my reasons are silly because then I
write incorrect code.  I say they are silly because you can write incorrect
code easily no matter what sized ints you use and my way saves me hours
of worry... again, a matter relating to experience, NOT 16/32 bit ints.

>Lois Mermelstein

			-Matt