Xref: utzoo comp.sys.mac.programmer:5340 comp.sys.mac:29472
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!sticks!dwb
From: dwb@sticks.apple.com (David W. Berry)
Newsgroups: comp.sys.mac.programmer,comp.sys.mac
Subject: Re: LSC3.0 brain damage (no it isn't!)
Keywords: stdio, pointers
Message-ID: <1155@internal.Apple.COM>
Date: 4 Apr 89 00:20:07 GMT
References: <1704@ncar.ucar.edu> <1259@usfvax2.EDU>
Sender: usenet@Apple.COM
Distribution: usa
Organization: Apple Computer
Lines: 23

In article <1259@usfvax2.EDU> pollock@usfvax2.UUCP (Wayne Pollock) writes:
>I think you should complain about the Sun, because your example shouldn't
>work.  A pointer is *not* an integer.  It is meaningless to try to print
>out pointers this way-- next time cast the pointer as an integer first, or
>use one of the ANSI C features that lets you print a pointer with a \p
>(incidently, this conflicts with current use of \p to indicate a pascal
>type string--I hope at least a warning will be generated in future LSC).
	Actually, there shouldn't be a conflict.  \p is used to generate
	a pascal style string and %p is used to print a pointer.

>
>I'm only guessing, but I think that on a mac, malloc generates a handle
>to some storage, not a simple pointer.  So the thing you kept decrementing
>was "*ptr", not"ptr".  Naturally "ptr" doesn't change each time.  (Any-
>body know if this is right?)
	Nope, malloc still generates a simple pointer.  The problem, as
	pointed out earlier, is that only the upper order bytes of the
	pointer were being printed out, and they didn't ever change.

Opinions:  MINE, ALL MINE! (greedy evil chuckle)

David W. Berry		(A/UX Toolbox Engineer)
dwb@apple.com		973-5168@408.MaBell		AppleLink: berry1