bartz@elbereth.rutgers.edu (Edward Bartz) (02/20/91)
I have noticed something rather strange, in changing over from
5.0a with 1.3 includes to 5.0d with 2.0 includes. Many system
routines that formerly expected (Char *) parameters now expect
(UBYTE *) parameters. While this is a small difference requireing
type casting, it is a pain to change all my source code. Is this a
perminent change (either bye manx or commodore), or is this just a
temporary screw up by Manx, to be corrected in the next update?
On a similar note, I notice that source code written by other
people (that use FileLocks) declare variables of the form
struct FileLock * fl;. And then, pass then to Lock,Unlock,etc. In
Manx, these routines have always been BPTR's. While I understand,
that these routines expect BPTR's, it seem that other compiliers
(SAS I assume) either declare file lock ptr's as BPTR's or
automatically convert during compiling. What's the story?
Ed Bartz
--
UUCP: bartz@elbereth.uucp
BITNET: bartz@rutphy.bitnet
USSnail: 12 Roosevelt St. South River, NJ 08882jesup@cbmvax.commodore.com (Randell Jesup) (02/21/91)
In article <Feb.20.10.22.45.1991.24248@elbereth.rutgers.edu> bartz@elbereth.rutgers.edu (Edward Bartz) writes: > > I have noticed something rather strange, in changing over from >5.0a with 1.3 includes to 5.0d with 2.0 includes. Many system >routines that formerly expected (Char *) parameters now expect >(UBYTE *) parameters. While this is a small difference requireing >type casting, it is a pain to change all my source code. Is this a >perminent change (either bye manx or commodore), or is this just a >temporary screw up by Manx, to be corrected in the next update? No we did it (though perhaps we should have made them BYTE *'s). > On a similar note, I notice that source code written by other >people (that use FileLocks) declare variables of the form >struct FileLock * fl;. And then, pass then to Lock,Unlock,etc. In >Manx, these routines have always been BPTR's. While I understand, >that these routines expect BPTR's, it seem that other compiliers >(SAS I assume) either declare file lock ptr's as BPTR's or >automatically convert during compiling. What's the story? Always has been BPTR, anyone who uses FileLock * is setting themselves up for a nasty suprise. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (02/22/91)
In article <2169@fornax.UUCP> laughlin@lccr.UUCP (Bob Laughlin) writes: >In article <19176@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> Always has been BPTR, anyone who uses FileLock * is setting >>themselves up for a nasty suprise. > > Then why do the Autodocs have things like, >struct FileLock *DupLock (struct FileLock *lock) ; >when they document dos functions? I thought Manx was just being lazy >in calling all dos pointers BPTR's. Because the people who wrote it were used to programming in BCPL. It's been fixed. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
peter@cbmvax.commodore.com (Peter Cherna) (02/23/91)
In article <1991Feb22.175826.26009@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > In 'C', a lock must be declared as a struct FileLock, less you could >not dereference its fields! The AmigaDOS functions return BPTR's to FileLock structures, not pointers to FileLock structures. I wouldn't recommend pretending that they return struct FileLock *. Dereferencing that will be nothing but trouble. I don't think there's much in a FileLock structure you should read, anyways. Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
bartz@elbereth.rutgers.edu (Edward Bartz) (02/25/91)
[peter@cbmvax.commodore.com writes] >nothing but trouble. I don't think there's much in a FileLock structure >you should read, anyways. > Peter Try writing a file system without getting inside FileLocks. :-} The answer to my FileLock question seems to be two parts. One, the autodocs were written in a confusing way. Which still seems to the case, since my copy of the 2.0 includes does the same thing, noting that it is a BCPL pointer only at the end. Second, many people were caught by this, but it didn't always matter. If you acquire a lock, and do nothing but pass it on to other routines (written correctly), it doesn't matter what you call it, the program is confusing, but functional. When I first start playing with this stuff, I made the mistake, but took it a step further. I filed in filelocks as c pointers. The strange thing was, it seemed to work. The program didn't crash, and seemed to work (since I wasn't sure at that time how things should work, any wierd responses I got seemed only to because the code wasn't yet complete). Now that I have this bit of confusion filled in, I know how to handle other peoples code. Ed Bartz -- UUCP: bartz@elbereth.uucp BITNET: bartz@rutphy.bitnet USSnail: 12 Roosevelt St. South River, NJ 08882