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,976a050e0f89277c X-Google-Attributes: gid103376,public From: gwinn@ma.ultranet.com (Joe Gwinn) Subject: Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP Date: 1998/04/16 Message-ID: #1/1 X-Deja-AN: 344553447 References: <352A79C2.15FB7483@nathan.gmd.de> <1998Apr10.073110.1@eisner> X-Ultra-Time: 16 Apr 1998 04:09:14 GMT X-Complaints-To: abuse@ultra.net Organization: Gwinn Instruments Newsgroups: comp.lang.ada Date: 1998-04-16T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe said > > < totally smooth, but the multiple-language problem isn't restricted to Ada, > and never was. > >> > > Please give us some details as to what is not smooth. I find it hard to > find any specific information in your message. What Ada 95 compiler have > you used? What specific difficulties have you had in interfacing to other > languages (in particular to C, Fortran or COBOL using the defined features > in Ada 95). It's a lot of little things, too many to really list in any detail. Alignment and padding of and between various size fields is a big issue, especially if the processor hardware in the various participating machines have different data alignment requirements. All the gritty details needed to ensure that data structures defined in two unrelated languages and compilers are absolutely congruent, to the bit, always and forever. I have never seen any real pattern implicating any one language or compiler, although one's chances are better if all involved compilers came from one source, and simpler languages tend to cause less trouble. No high-order language really allows one to fully control the representation of complex data structures in memory, although some give it more lip service than others. Assembly code will never die; it may be ugly, but it always works, and it's unlikely to try to outsmart you. If you are trying to verify or improve GNAT's interface to C and/or UDP messages from other machines of different manufacture via communications, I would try to implement something that handles complex UDP messages sent between these three worlds, and see how it goes. I bet you will find lots to fix; we always do, but are forced to evade rather than really fix things, not having command of the Ada compiler. Then, when it all seems to work, add a field to the beginning of a message format, upgrade a compiler or two, and change a machine type or two. One thing that has improved noticably over the last decade is that hardware floating point formats are now pretty much standardized under IEEE Std 754. In the old days, you only rarely could afford to have floating point variables in messages sent between different kinds of machine as no two floating point formats were the same. Now, if the machines are of the same endian persuasion, 32-bit and 64-bit floats in messages work just fine. The other IEEE float formats aren't universally supported. Joe Gwinn