Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.programmer Subject: Re: Aztec C 5.0d w/ 2.0 includes. Char vs. UBYTE Message-ID: <19176@cbmvax.commodore.com> Date: 21 Feb 91 00:27:38 GMT References: Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Distribution: na Organization: Commodore, West Chester, PA Lines: 29 In article 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") ;-)