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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,235855e3822c83d1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Received: by 10.205.123.140 with SMTP id gk12mr1164269bkc.1.1335515099842; Fri, 27 Apr 2012 01:24:59 -0700 (PDT) Path: h15ni170833bkw.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Importing C function with variable argument list Date: Fri, 27 Apr 2012 08:24:59 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <610ee323-4c7f-413d-8568-aed4955f5152@z38g2000vbu.googlegroups.com> <1288794.275.1334249936588.JavaMail.geo-discussion-forums@ynlp2> Mime-Version: 1.0 Injection-Date: Fri, 27 Apr 2012 08:24:59 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="614"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18lE4zuCSZE6gnKobo2bisb" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:+yMht1nsRsjaxIdkCdBpdlfozkM= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Date: 2012-04-27T08:24:59+00:00 List-Id: Hello, On 2012-04-12, Randy Brukardt wrote: > "Adam Beneschan" wrote in message > news:1288794.275.1334249936588.JavaMail.geo-discussion-forums@ynlp2... > On Thursday, April 12, 2012 3:08:28 AM UTC-7, Markus Schöpflin wrote: > ... >>> So the note from the Ada RM does not seem to be followed by GNAT >> >>I don't think GNAT has a choice whether to follow it or not, since GNAT >>can't be expected >> to know what the code of the imported C subprogram is going to look like. >> All it can do is >> obey what the user tells it to do. > > Right. If the calling convention is different for normal C subprograms and > vararg ones, then clearly there needs to be a different convention name for > varargs. (As I noted, I've never worked on such a machine, but it doesn't > surprise me that much that they exist.) > > Probably the RM ought to suggest such a convention name as Implementation > Advice (something like C_Varargs) in order to increase portability. > > Someone ought to submit a suggestion to Ada-Comment so that it gets on the > ARG's radar/agenda. Sorry for the "necromancy", but I thought it might be useful to add: Another significant difference between varargs and regular arguments is "type promotion". Briefly, char and short types are promoted to int when they are part of a variadic argument, while they are not when they are an explicit argument. So the following will probably fail more reliably than previous examples: function Print_Short (Format : in Interfaces.C.char_array; Value : in Interfaces.C.short) return Interfaces.C.int; pragma Import (C, Print_Short, "printf"); Would you all mind testing this on various platforms? Moreover, the argument type promotion also happens in non-prototyped functions (e.g. K&R style). For example consider the following C function: void print_k_r_short (); void print_k_r_short (s) short s; { printf ("%hd\n", s); } Then the following Ada import is unlikely to work: procedure Print_K_R_Short (S : in Interfaces.C.short); pragma Import (C, Print_K_R_Short, "print_k_r_short"); Though in that case, using Interfaces.C.int would work. Of course, on platforms where calling convention transmits C.short arguments exactly like C.int (e.g. for improved alignment, or because the platform has C.short equivalent to C.int (but then you could use C.char instead of C.short, since C.char is guaranteed to be strictly smaller than C.int on conforming hosted implementations)). Hoping this helps, Natasha