From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c6e016ae58737f34 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: win32ada design question/problem Date: 1998/11/17 Message-ID: #1/1 X-Deja-AN: 412892370 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <72shhh$8cg$1@nnrp1.dejanews.com> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-11-17T00:00:00+00:00 List-Id: dennison@telepath.com wrote: : ... : I'm trying to write some portable bindings to the Zlib compression library : right now, and have found myself reverting to just that. But are there : portability issues associated with System.Address? My reading of 13.7 is that : System.Address does not nessecarily map to a C pointer, and that : System.Null_Address does not nessecarily map to a C null pointer. : The "portable" alternative we are given is Interfaces.C.Pointers. But its a : real pain to use for routines where the input object could be any type. I would not worry about the portability of System.Address. Theoretically it might be a problem, but practically, I doubt very much whether you will run into any problems on hosts and targets you care about. System.Null_Address is perhaps slightly more likely to cause portability problems, though still I suspect you are in the 0.01% case. You could always define your own "C_Null" in some common target-specific package, with the 99.99% reusable default definition of System.Null_Address. : -- : T.E.D. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company