Variable arguments magic in Ada to C code

Variable arguments magic in Ada to C code

[Andreas Almroth]

G'day netfolks,

I'm this close <--> declaring my self dummy in Ada, which could very well be
true... ;-)

I'm trying to create a variable argument list in my Ada code, to a piece of
C code. The C code works fine on several platforms, so I'm quite sure I'm 
the one doing wrong... :-(

I searched google and found a few quite valuable replies to this question,
but I have found that my implementation is still not working. I'm developing
on Sun SPARC with Solaris 8, and just can't get my code to work.
The first argument passed works just fine, but the rest are not interpreted
very well by the C code. An 32/64 bits issue?

I have checked the GNAT source code, and I have tried to do the same thing
as they do there, but can't get it to work. I also need to transfer pointers 
to other types than strings (assuming this might prove harder than I thought).

Well, before publishing my code to further scrutiny and laughter, I thought
I would ask this kind newsgroup to pointers of information, or even better, to
working examples (other than GNAT source)...

Kind regards,
Andreas

--
Remove -nntp to mail directly

Re: Variable arguments magic in Ada to C code

[Lutz Donnerhacke]

* Dale Stanbrough wrote:
>Lutz Donnerhacke wrote:
>> >Anyway, I think I'm heading the right way, found the X11Ada binding which
>> >includes a stdarg package doing just what I want. This excellent package
>> >is written by Mitch Gart.
>> 
>> Personally I find this package horrible. It will take some minutes before I
>> can eat something again.
>
>Strange reaction. Perhaps you should move to another business.

This is no option.

>If you need to interface to software written using varargs, then I'm
>not sure what you are suggesting one should do.

Offer the strong typing features by declaring each argument count as a
seperate function/procedure. Import those from the same linker name. This is
recommended in the ARM. It works. If you need also variable argument types,
use generics for Import.

If you need to provide such a function, you have to use a completely
different approach: You have to have a deep look into the calling system of
your other world compiler ...

Re: Variable arguments magic in Ada to C code

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> * Andreas Almroth wrote:
>>The first argument passed works just fine, but the rest are not interpreted
>>very well by the C code. An 32/64 bits issue?
>
> No, but I do not understand the problem:
> ARM B.3 says in Note (12):
>    A C function that takes a variable number of arguments can correspond to
>    several Ada subprograms, taking various specific numbers and types of
>    parameters.

The calling convention of a C function which expects a variable number
of arguements can differ considerably from one which does not.

Your example is not portable.

Re: Variable arguments magic in Ada to C code

[Lutz Donnerhacke]

* Florian Weimer wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
>> * Andreas Almroth wrote:
>>>The first argument passed works just fine, but the rest are not interpreted
>>>very well by the C code. An 32/64 bits issue?
>>
>> No, but I do not understand the problem:
>> ARM B.3 says in Note (12):
>>    A C function that takes a variable number of arguments can correspond to
>>    several Ada subprograms, taking various specific numbers and types of
>>    parameters.
>
>The calling convention of a C function which expects a variable number
>of arguements can differ considerably from one which does not.

This would cause major problems when compiling legal C code without advanced
prototypes for such function.

>Your example is not portable.

What is the portable (right(TM)) solution?

Re: Variable arguments magic in Ada to C code

[Dale Stanbrough]

Lutz Donnerhacke wrote:

> What is the portable (right(TM)) solution?


Perhaps the portable solution is to fully document
how you determine what the calling conventions for 
a C Vararg list are.

Unless of course it makes you queasy...

Dale

Re: Variable arguments magic in Ada to C code

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

>>The calling convention of a C function which expects a variable number
>>of arguements can differ considerably from one which does not.
>
> This would cause major problems when compiling legal C code without
> advanced prototypes for such function.

Yes, these problems exist.  So what?

>>Your example is not portable.
>
> What is the portable (right(TM)) solution?

Writing intermediate C wrappers?

Re: Variable arguments magic in Ada to C code

[Lutz Donnerhacke]

* Florian Weimer wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) writes:
>>>The calling convention of a C function which expects a variable number
>>>of arguements can differ considerably from one which does not.
>>
>> This would cause major problems when compiling legal C code without
>> advanced prototypes for such function.
>
>Yes, these problems exist.  So what?

I can't believe such a brain damage. There must be something really huge
hitting and smashing the inventors head.

>>>Your example is not portable.
>>
>> What is the portable (right(TM)) solution?
>
>Writing intermediate C wrappers?

*wrgs*

Re: Variable arguments magic in Ada to C code

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

>>>>The calling convention of a C function which expects a variable number
>>>>of arguements can differ considerably from one which does not.
>>>
>>> This would cause major problems when compiling legal C code without
>>> advanced prototypes for such function.
>>
>>Yes, these problems exist.  So what?
>
> I can't believe such a brain damage. There must be something really huge
> hitting and smashing the inventors head.

Quite a lot of GNU C code breaks when compiled with a conforming
C compiler because prototypes do not match old-style function
definitions (I'm not sure if prototypes were allowed at all for
old-style function definitions before C99).

Re: Variable arguments magic in Ada to C code

[David Thompson]

Andreas Almroth <andreas-nntp@almroth.com> wrote :
> lutz@iks-jena.de (Lutz Donnerhacke) writes:
[ calling C variable-argument functions ]
> Well, I'm merely interfacing to an existing C library. I do heaps of type-
> and value checking before passing on to the C function, and thus trying to
> limit the consequences of incorrect arguments.
...
> > >When using VA in C, you build a list of pointers (System.Address) to your
> > >arguments, and terminate the list with NULL (Null_Ptr).
> >
Not true, at least not in general.  The actual argument-passing
mechanism(s), for both vararg and non-vararg functions, are not
defined by the C standard only by implementation(s) (so in principle
you need to say not "in C" but "in MSVC++6" or "in gcc 3.0" etc.),
but in practice at least varargs are passed in consecutive memory
(modulo padding needed for alignment) usually on the stack or
possibly in other "standard" (for the platform/architecture) places
like the VAX AP-addressed arglist or S/370 R1->caller memory.

For _some_ functions, some or even all of these arguments
are pointers, e.g. the *scanf family and in Unix/POSIX execl*.
The latter are terminated by a null pointer; the former are not.
For other functions, like *printf, (most of) the arguments are
not pointers at all.

There is an important distinction however between a function
which actually takes variable arguments, and a function which
takes a va_list (or pointer thereto), which is a single, fixed,
but opaque and implementation-dependent type that allows
the callee to access the variable-arguments of the _caller_.

> > No. You pass a controlling argument which is parsed and interpreted by the
> > called function. In my previous example it was simply a count value.
> >
Usually but not necessarily.  What is absolutely true is that
the called function must (be able to) determine the number
and type(s) of arguments somehow _before_ accessing them --
no checking or conversion is provided by the varargs mechanism.
This _may_ be the format specifier substrings in *printf/*scanf,
a null or other sentinel value as in execl*, a count,
or anything else you care to code that works for your data.
It _could_ be global/shared data, or a callback function,
or something even more bizarre, although if you do such things
don't expect anyone else to accept or reuse your code.

> > Inband-terminated arrays are used to pass arrays in C. In Ada you pass the
> > array bounds out of band, so you never need this data manipulation.
> >
Actually inband termination is mostly used in C for array of
character representing a string.  Arrays of other types are
(more?) commonly dimensioned by counts passed explicitly
or implicit in e.g. global state, and sentinel values IME rather
rarer though certainly used in some cases.

> > >You then pass the pointer to the list, as the last argument to the C
> > >function. With the VA_* macros you then traverse the pointers and type
> > >cast to whatever suitable (as in printf, you know by the format string
> > >what to expect).
> >
> > No, this is not the way stdarg works. You access the first few arguments of
> > the function and the iterativly get the next argument. There is no problem
> > in causing strange errors by calling a function with the wrong number of
> > arguments. The called function will reinterpret the stack as arguments or
> > crash or do something much more strange.
> >
>
To be a bit more specific:
The callee accesses all fixed arguments (parameters) as normal,
and the variable arguments iteratively using a va_list whose initialization
(by va_start) requires specifying the last fixed parameter (which must not
be of a type that gets automatically "adjusted") -- in practice this
(always?) accesses varargs which are passed in consecutive memory
either just after that last fixed argument or in a location determined by
the calling mechanism independent of the fixed argument(s),
and the va_list is really just a pointer that scans across that memory,
but that mechanism is not required.

Yes, if the callee does try to "receive" argument types that don't match
those the caller actually passed, except for a few minor variations
allowed by the default argument promotions and (arguably) type
compatibility rules, you get Undefined Behavior (= Ada erroneous)
which will typically do something Weird or Very Bad or both.

A vararg-callee can further pass its varargs (or a suffix of them)
as a block to lower-level routines, by passing the va_list.  It is
not defined whether va_list is an array type, and thus is effectively
passed by reference and shared rather than by value, so if you
need copy semantics -- that is you need to access the varargs
in both the direct-callee and a further-callee -- in C89 you can
and theoretically must create and destroy (va_end) separate or
disjoint va_list's, although in practice just copying the va_list
works, and C99 makes this official (va_copy).  For example,
printf can be implemented by just passing its arguments to
vprintf (or perhaps vfprintf) which does the actual work; you
can write your own vararg function which includes (modified)
printf semantics that also calls vprintf etc. etc.

(Aside:  saying that there is 'no problem' with something normally
connotes that it is OK, good, satisfactory, manageable.  I assume
you meant "there is no difficulty in causing (trouble)", but it is simpler
and IMO clearer to use the positive "it is easy to cause (trouble)".)

--
- David.Thompson 1 now at worldnet.att.net

Re: Variable arguments magic in Ada to C code

[David Thompson]

Florian Weimer <fw@deneb.enyo.de> wrote :
> lutz@iks-jena.de (Lutz Donnerhacke) writes:
...
> Quite a lot of GNU C code breaks when compiled with a conforming
> C compiler because prototypes do not match old-style function
> definitions (I'm not sure if prototypes were allowed at all for
> old-style function definitions before C99).

This is not very clear; I think you mean declarations using
prototype syntax (new in C89/90, like C++) in calling code
for a function whose definition (implementation, body) uses
old-style (K&R1) parameter declaration syntax.  If so, you
_can_ (since C89) write a prototype correctly matching any
definition that was legal in K&R1 -- but you must be careful,
because parameters of "less than normal width" types,
specifically integer types below (signed or unsigned) int
and float (the only floating type below double) were promoted
in K&R1 calls and thus the promoted types must be used
in the prototype to get the correct matching, even though
the definition can be written with the narrower type(s).

gcc will warn about mistakes here if the prototype declaration
is visible at the definition (e.g. by #include'ing the "spec" .h
in the "body", a commonly recommended practice) if you use
-pedantic, at least 2.95.2 which is what I have handy to check.

If this is meant to relate to the earlier posts about vararg versus
non-vararg functions in C, there was and is no K&R1 syntax
for vararg -- the _only_ correct way to call or define/implement
vararg functions in C is with prototype syntax.  (Or of course
a compatible implementation of another language, like Ada.)

--
- David.Thompson 1 now at worldnet.att.net