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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,56daebc125c71dd1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-12-08 14:14:04 PST Path: bga.com!news.sprintlink.net!sundog.tiac.net!news.kei.com!world!blanket.mitre.org!linus.mitre.org!linus!mbunix!emery From: emery@goldfinger.mitre.org (David Emery) Newsgroups: comp.lang.ada Subject: Re: Rocket Science? Date: 8 Dec 94 16:23:14 Organization: The Mitre Corp., Bedford, MA. Message-ID: References: <9412081713.AA03077@eight-ball.hv.boeing.com.hv.boeing.com> NNTP-Posting-Host: goldfinger.mitre.org In-reply-to: Bob Crispen's message of Thu, 8 Dec 1994 11:13:07 CST Date: 1994-12-08T16:23:14+00:00 List-Id: The 'right way' to implement this is to use an enumeration type, but to hide the mapping/representation. There's no guarantee that AF_UNSPEC = 0 and/or AF_UNIX = 1 and/or AF_UNSPEC > AF_UNIX. In fact, I've seen situations where the ordering of #define values was significantly different on different machines for the same header file. When you specify an enumeration type, you specify the ordering of the values. If the underlying C binding does not 'respect' this ordering (and there's no particular requrement that it do so), then you're in very serious trouble when you port the binding. The package specification has to change, and who knows the ramifications of this change. Additionally, I've encountered problems with the size of enumeration types. Some implementations have rejected a size clause for an enumeration type (I won't mention any names here, but it's a compiler that otherwise has gotten a lot of 'respect'...) when the request size is greater than what the compiler wants to allocate. When this happens, again you're in serious trouble. So here's how I handle this particular situation: from C: #define AF_UNSPEC 0 #define AF_UNIX 1 (void) (dom); int dom; {...}; package spec: package is type Domains_And_Addresses_Families is ( AF_UNSPEC, -- Unspecified AF_UNIX, -- Unix internal protocols... ...); procedure (the_domain : Domains_And_Addresses_Families); end ; package body with C_Types; -- Ada83 analogy to Ada95 package Interfaces.C package body is package C_Interfaces is procedure (dom : C_Types.int); pragma interface (C, ); LAST : constant C_Types.int := ; domains_to_int : constant array -- note anonymous array object here (domains_and_adresses_families) of C_Types.int := (AF_UNSPEC => 0, AF_UNIX => 1, ...); int_to_domains : constant array (C_Types.int range 0..last) of domains_and_adresses_families := (0 => AF_UNSPEC, 1 => AF_UNIX, ...); end C_Interfaces; procedure (the_domain : Domains_And_Addresses_Families) is begin C_Interfaces. (dom => C_Interfaces.domains_to_int (the_domain)); end ; end ; The reason for the nested package in the body is so I can use the exact C function name in the nested package without any overloading problems for operations defined in the parent package. (In Ada95, would this be a good place for a private child package?) If the integer values aren't contiguous, then you can write a simple function function int_to_domains (int : C_Types.int) return domains_and_addreses_families; that does the reverse mapping. The nice thing is that this change in package C_interfaces is completely transparent to the rest of the implementation. (When used on the 'right hand side', array indexing and function calls look the same.) --------------- In summary, it's not hard to cobble up something that works for a given Ada/C/API implementation. It IS hard to define an Ada binding that is portable (at least at the package specification level) across multiple Ada/C/API trios. I've been at this for 10 years, and I'm still learning what works and what doesn't work. dave p.s. For more information on how to do Ada bindings "right" , see the POSIX/Ada rationale (IEEE Std 1003.5-1992), and my paper in the proceedings of TRI-Ada '90 on my prototype implementation of POSIX/Ada. Since the TRI-Ada '90 paper, I've learned a bunch more tricks, etc, but I haven't had the chance to write a successor paper. -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth -------------------------------------------------------------------------