home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.programmer
- Path: sparky!uunet!mcsun!sunic!liuida!isy!lysator.liu.se!boberg
- From: boberg@lysator.liu.se (Stefan Boberg)
- Subject: Re: What is (APTR) ?
- Message-ID: <1641@lysator.liu.se>
- Sender: news@isy.liu.se (Lord of the News)
- Organization: Lysator Academic Computer Society, Linkoping University, Sweden
- References: <9209140718.AA09878@teetot.acusd.edu> <copes.716466012@marsh> <1630@lysator.liu.se> <1992Sep14.130914.13505@ida.liu.se>
- Date: Tue, 15 Sep 1992 11:02:22 GMT
- Lines: 34
-
- micja@ida.liu.se (Michael Jansson) writes:
- > boberg@lysator.liu.se (Stefan Boberg) writes:
-
- >> Excerpt from `exec/types.h' :
- >>
- >> /* WARNING: APTR was redefined for the V36 Includes! APTR is a */
- >> /* 32-Bit Absolute Memory Pointer. C pointer math will not */
- >> /* operate on APTR -- use "ULONG *" instead. */
- >> ^^^^^^^^^
- >>
- >> BTW: Why isn't this "UBYTE *" ?? Why on earth would anyone want ULONG
- >> pointer arithmetic?
-
- >Have you ever used Tags? Process a file like Font:CGTimes.otag and you will
- >find several reasons for doing pointer maths (trust me) on ULONG:s.
-
- Sure, but when working with tags you work with TagItem structures and
- the corresponding utility.library functions to obtain the taglist entries.
- You should never directly address a TagItem list by doing pointer
- arithmetic on the taglist pointer.
-
- My point was that since 680x0 memory is built up from bytes, the
- most natural pointer type would be `char *' (or UBYTE *, to use CBM
- terminology).
-
- Anyway, I really don't care since I never use the types defined in
- <exec/types.h> ...
-
- > Michael Jansson mij@IDA.LIU.SE, uunet!liuida!mij, mij@SELIUI51.BITNET
- --
- Stefan Boberg - AP & EE student at Linkoping Institute of Technology, Sweden
- Author of LhA, ArjA and LhArcA. Co-author of Alien Breed, Project X, Full
- Contact and Miami Chase.
- EMail: boberg@lysator.liu.se, lha@augs.se FidoNet: 2:204/404
-