Ada in gcc-3.4.3 on x86_64

[Robert Dewar]

Dean Kolosiek wrote:

> Speed does not have precedence over correctness. 

Of course, but there is no correctness issue here, since there
is no requirement to support variadic functions (given that
Ada has no equivalent).

>> The above is a note, which has no normative force whatsoever. 
>> Furthermore.
>> it says "can" which in standardeese means that this is an allowable
>> implementation option.

> No. Get a dictionary. "Can" denotes ability. The word you defined is
> "may".

Well since I helped write that note, I think I can comment on the
intention :-) This is only a note, because there is nothing in the RM
that says that the variadic case must be supported.

What the note was intended to mean was that *implementations* can
provide this facility if they want, that there is nothing in the
RM to prevent this. Generally if something is not prohibited, it
is allowed. That's all the note is pointing out. It has nothing
to do with establishing even implementation advice, let alone
an implementation requirement. The note is not saying that users
can necessarily do this. I advise in general against reading notes.
If you can't derive something that you are looking for from the
normative text, the notes lend nothing at all. If you think they
do, then you are definitely misintepreting the notes. In other
words, notes are always conclusions that you could draw in any
case without reading them.

> Notes have no normative
> force whatsoever.  A statement to allow an implementation would be 
> normative. 

No, that's not right, implementations can do anything they like
if it is not specifically prohibited by the normative text.

> An allowance
> expresses something that is not otherwise permitted. The use of  
> overloading to call variadic
> functions is fully correct without an allowance. The note is not a 
> suggestion, it is a statement of fact.

Not at all. There are architectures on which the calling sequence for
an n-adic function, and a variadic function with n arguments are
radically different. So if you interpret the note to mean that you
always expect one syntactic form to cover both cases, that's simply
plain impossible on some architectures, e.g. MIPS/Irix if I remember
correctly.

> If you want to make a new pragma

It would be a new convention rather than a new pragma. Convention names
are generally not portable. For example, on a given system you might have
multiple callings sequences for different C compilers (this was true in the
past on the PC, and is still true to some extent wrt the stack alignment
issue). On such a system the normal way of handling this would be to have
separate convention names for the two compilers. GNAT has introduced a
useful pragma Convention_Identifier to allow a level of indirection of
convention names in such cases, but the ISO standards group decided not
to standardize this pragma.

>  in order to handle the impossible 
>> situations you should get it into
>> Ada 2005 to make it portable.

Well I am not sure about the "you" here. Personally I don't
feel there is enough demand to put this in. No one (including
apparently you) has submitted a comment on this issue so it
seems like it is hardly an important issue. This is potentially
quite a lot of work for limited gain (since C wrappers can
always be written).

If you feel otherwise, I would recommend sending a comment
in right away (see RM for details on comment submission,
Forward, paras 58-65). It is getting late in the process, but
if you get this in right away, it might still be in time to
be considered for inclusion.

Finally, if you want to investigate implementing this useful
feature (I am not saying it is not useful, just that useful
is not a sufficient criterion for inclusion in the standard),
then we would welcome a patch submission that would provide
this functionality.

Here would be my specification of this feature

  A new convention identifier C_Varargs is introduced. This convention
  may only be used in the context of a pragma Import. It indicates that
  the function being imported is a varargs function in C, so that the
  appropriate calling sequence must be used. On the Ada side, there is
  no direct facility for allowing a variable number of arguments. However
  it is possible to use multiple imports for different arguments. For
  example, we might have for printf:

     procedure printf_int (S : Interfaces.char_array, V : interfaces.int);
     pragma Import (C_Varargs, printf_int, External_Name => "printf");

  Note: on some architectures, the calling sequences for an n-adic function
  and a variadic function with n arguments are the same. On such architectures
  the convention C_Varargs will be equivalent to the convention C. However
  there are architectures where the calling sequences are different, and that
  is why in general two convention identifiers are required.

I have copied Ed Schonberg and Gary Dismukes on this (both ARG members from
AdaCore) in case they are interested :-)

Robert Dewar