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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: String parameters to exported routines - What should a compiler do? Date: 1997/06/10 Message-ID: #1/1 X-Deja-AN: 247442454 References: Organization: New York University Newsgroups: comp.lang.ada Date: 1997-06-10T00:00:00+00:00 List-Id: Tuck says <> I strongly disagree. I think this is error prone, and no, GNAT does NOT do this, and regards the construct as illegal or generates a warning, I can't remember which right now, I think in fact it should be illegal. If you pass a string from a C program to an exported Ada program, e.g. "abc", and you allow a construct with String as a formal on the Ada side, typical programmers who do not understand the issues will expect the bounds to be 1..3, and their programs will go berserk overwriting memory when they use 'Range. It should never be this easy to import this kind of overwriting into an Ada program. If you want the effect that Tuck recommends, then get it by defining a type subtype Big_String is String (Natural); and use this as the type. These kind of types (we always call them Big_xxx by convention in the GNAT sources) are often useful in dealing with cases where bounds are simply not available. They have the advantage of constantly reminding the programmer that the bounds are NOT available. Yes, I know AdaMagic supplies bounds in this case, and we considered doing this in GNAT as well, but rejected the idea as too dangerous, per above reasoning. Generally it is of course desirable for Ada 95 compilers to do the same think in the same situation, but it is not an absolute principle, and when compilers do things that are outside the RM (you cannot deduce Tuck's recommendation from the RM), they should not always be copied. Sometimes it seems reasonable to copy things. For example, even though the AdaMagic C_Pass_By_Copy facility is a bit of a kludge (a sufficient kludge that the ARG cannot yet bring itself to endorse this as the proper solution to the error in the RM, see below), it seemed reasonable to copy this into GNAT, and indeed the ARA (not quite so bound as the ARG by considerations of elegance :-) decided that this should be the common approach. P.S. the RM error I refer to above is the recommendation that all structs should be passed by reference. This was a plain mistake, since it would forbid compilers from duplicating the typical C callings sequence in which small structs are passed by copy in registers. (we are talking here specifically about passing mechanisms for convention C) Finally, Tuck says there is no difference between export and import with regard to the original topic. That's quite wrong. Importing functions is not a problem. It is fine to discard bounds on the way to C, since C does not expect the bounds anyway. On the other hand, exporting is a real problem. Here we have no bounds on the C side. Tuck recommends implicitly generating bogus bounds on the way to Ada GNAT feels that it is safer not to allow the notation, given that it adds danger, but no expressive power.