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,b643449bd65c29dc,start X-Google-Attributes: gid103376,public From: gwinn@ma.ultranet.com (Joe Gwinn) Subject: Interfacing Ada95 programs to each other and to C and C++ Date: 1998/05/10 Message-ID: #1/1 X-Deja-AN: 352045837 X-Ultra-Time: 10 May 1998 22:43:12 GMT X-Complaints-To: abuse@ultra.net Organization: Gwinn Instruments Newsgroups: comp.lang.ada Date: 1998-05-10T00:00:00+00:00 List-Id: This is my current list of issues in interfacing Ada95 programs to each other and to C and C++ programs. Some of these issues have been mentioned in prior postings, but are repeated here for completeness. We are still integrating, so not all issues have been uncovered and solved. The prime requirement is not just successful interfacing, it's bulletproof target-independent, compiler-independent portable interfacing. There are many solutions that will work for one or another specific pair of compilers and/or languages, but very few solutions will work for any or even most pairs. Why is this important? Because with the short lifetimes of current compiler versions and COTS targets, we will port our code many times in the development and life of the code, and it's too expensive and error prone if the interfaces (many having hundreds of message types) fall apart every time something is changed. There are two related interface areas, procedure call conventions and handling of data and data structures passed through the procedure call interface, and the passing of messages (moveable data structures) between programs in various languages via some kind of communications system. In procedure call issues, at least the target processor is the same. 1. Alignment clauses do not necessarily govern dynamic objects (those declared in procedures rather than the main). Things that must be aligned must thus be handled at the "main" level, or alignment commands will be ignored. This matters for two reasons. First, many realtime communications systems require specific data alignments. Likewise, I/O drivers and hardware. Second, different compilers, especially if targeted on different processors, often pad the elements of data structures differently. If one makes all fields 32-bit items, padding is lass variable. 2. Rep specs cannot be used on enumeration types (because many compilers generate tremendous amounts of code to handle all possible cases, however unlikely), so one cannot use enumeration types in messages. 3. If an integer field in a record is a subrange type, Ada will tend to use the smallest kind of integer that will hold the field, overriding any rep specs to the contrary. Other languages and compilers, especially on different targets, may chose different kinds of integer and different paddings. This too can be solved by making all integers 32-bit, and dropping any use of subranges (and the attendant range checks). 4. There may also be a endian problem; we haven't completely sorted this out yet, but we have cases where the wrong end of a 32-bit integer is kept as a packed subrange. This may just be a bug. 5. Floating-point fields, 32-bit and 64-bit IEEE 754, have caused no problems so far, even between machines of differing type, something of a surprise. Floating point is more complex than integers, and some machines have somewhat different endian behaviour for floats than for integers. These are the causes of most problems we have seen so far. Simple human error has accounted for the rest. Joe Gwinn