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,6491d3799d35186b X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: String parameters to exported routines - What should a compiler do? Date: 1997/06/09 Message-ID: #1/1 X-Deja-AN: 247272958 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1997-06-09T00:00:00+00:00 List-Id: Kevin D. Heatwole (heatwole@his.com) wrote: : I am still struggling to figure out exactly what a compiler should do when : the Ada program contains an exported subprogram that has a parameter that : is unconstrained. We have implemented what we thought was a reasonable : thing to do, but now I am having second thoughts. It is not a question of whether or not the subprogram is exported. Rather, it is a question of the "convention" specified in the Export, Import, or Convention pragma. : What *should* a good Ada95 compiler do? I don't want to know what is legal : or simply permissable, but what is expected for an Ada95 compiler. : Here is an example: : procedure S (Item : String); : pragma Export (C, S); : Should this be legal or should the declaration of S be rejected? This should be legal. : If legal, should the compiler issue a warning that calling S from C : involves passing the bounds of item in a compiler-dependent form? The bounds should not be passed because the specified convention is "C" which does not pass bounds. : Or, should the compiler just generate code for the body of S that expects : Item to just be the address of the first character that comprise the : string and the bounds are assumed to be Positive'First .. Positive'Last (or : whatever the bounds are on the index subtype)? This is what I would recommend. Use the bounds of the index subtype. : Would the answers to the above make any difference if the parameter's type : was Interfaces.C.Char_Array? No. : What if S were called by Ada instead of C? Should the Ada call pass the : actual bounds to S whereas the C call gets away with just passing the : address of Item? No, the bounds should not be passed in either case. (Unless you have two entry points, I can't quite imagine how you could pass the bounds in one case, and not in the other.) : Finally, what if S were imported instead? Should Ada calling S just pass : the address of the first character of Item and just omit the bounds : altogether? Import vs. export is irrelevant. What matters is the "convention." If the convention specifies a language that doesn't pass implicit array bounds (or accessibility level, or the "'Constrained" bit) on the given target, then they should not be passed. For export, you need to "manufacture" the information, and for array bounds, using the index subtype seems best. For accessibility level, presume library level, and for 'Constrained, presume unconstrained. In other words, assume the most flexible answer, and let the user pass other explicit parameters if necessary to determine the "true" bounds, accessibility, etc., as would be required in C or other descriptor-less languages. : What do other Ada95 compilers do? The suggestions above conform to the AdaMagic-based compilers. I believe GNAT uses the same approach, though presumably an ACT person can give you the official answer. Note that for Java, length is passed along with the array, so you only need to "manufacture" the low bound (from the index subtype); the high bound can be computed. : Sorry for all the questions but I want to make sure that we handled this : case in the best manner possible. We are about to make major release of : our PowerAda compiler and I don't want to miss an opportunity to make this : "right" (if we don't already handle this "right"). : Kevin Heatwole : OC Systems, Inc. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA