Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!bbn.com!nic!chaos.cs.brandeis.edu!chaos!phils From: phils@chaos.cs.brandeis.edu (Phil Shapiro) Newsgroups: comp.sys.mac.programmer Subject: Re: Detecting Color Depth Message-ID: Date: 9 Nov 90 17:26:02 GMT References: <1990Nov6.231358.18153@Neon.Stanford.EDU> <8068@adobe.UUCP> Sender: @chaos.cs.brandeis.edu Distribution: na Organization: Symantec Corp. Lines: 22 In-Reply-To: hawley@adobe.COM's message of 8 Nov 90 23:01:21 GMT In article <8068@adobe.UUCP> hawley@adobe.COM (Steve Hawley) writes: In article phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >#define ScreenDepth(gdh) ((**((**gdh).gdPMap)).pixelSize) >#define MaxColors(gdh) (1L< >where gdh is a GDHandle (graphic device handle). Phil -- if your handle is not locked, isn't there a potential problem with the order of evaluation of the dereferences --especially in a context that may move memory? Actually, I don't think so -- the code ScreenDepth() generates will completely evaluate to the contents of the pixelSize field without moving memory. If pixelSize were an array or struct (like bounds) then this could cause problems. My macro is a bit sloppy, though, I really should have used (**(gdh)) (not (**gdh)) in the macro body. -phil -- Phil Shapiro Technical Support Analyst Language Products Group Symantec Corporation Internet: phils@chaos.cs.brandeis.edu