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,747d1273d7d099f X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Interfacing to C, output arrays Date: 1996/12/07 Message-ID: #1/1 X-Deja-AN: 202859019 references: organization: New York University newsgroups: comp.lang.ada Date: 1996-12-07T00:00:00+00:00 List-Id: Simon says Yes, I quite understand that; the problem is that the C subprogram is a function and therefore can't be declared with an out parameter. I guess I could use the DEC pragma (valued_subprogram??), but that would be a tad implementation-dependent! Sure, it would be a bit implementation dependent. At the moment it would only work on GNAT and DEC, though I would like to see this particular pragma (Import_Valued_Procedure) implemented more widely, since it is very useful in interfacing. It is indeed the sad consequence of the rule forbidding out parameters in functions that the horrible copy in your suggested solution is the only truly portable way of doing things. Probably your original dubious method of passing an in parameter will work. We assume you have used a pragma Convention (C,..) for the type of Arr (or the whole interfacing call is dubious), and it seems reasonable to assume that any reasonable compiler will in fact pass the array by reference in this case, in accordance with B.3(70): 70 An Ada parameter of an array type with component type T, of any mode, is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T. So probably you should go back to your original scheme. If you like in GNAT you can suppress the warning with a pragma Warnings (Off) just before the line that gets a warning, and a pragma Warnings (On) right after. Actually it is not only in the interfacing context that the inability to have procedures with in out parameters can be annoying. Consider the definition of Random in the RM, it modifies its generator argument. The only really "correct" way to implement this function in Ada is to make the type Generator be a controlled pointer into the heap, but this is nasty overkill, and nasty implicit heap use, so if you look at the GNAT implementation, you will find that it uses the same trick of "knowing" that an IN parameter is passed by reference and hence can be modified. Of course the GNAT runtime library only has to be portable to GNAT :-) P.S. This is not intended to start a thread on whether it is a *good thing* to allow in out or out parameters for functions. This point has been argued to death more than once before, and the bottom line is that opinion is strongly divided, but that there does not begin to be a consensus for making this change to the language, and those who oppose it feel strongly. They know quite well the arguments on the other side (which *I* strongly support), but find them unconvincing. Fair enough -- that's why the change was not made, but it does not stop it from being an annoying pain-in-the-neck! P.P.S. In the realm of further non-portable solutions, note that GNAT's unrestricted_access attribute could be used to avoid the copy in Simon's truly portable solution, but then of course it would not be truly portable any more :-)