Re: [Vala] ellipsis forwarding

[Jan Hudec <bulb ucw cz>]

On Fri, Apr 16, 2010 at 14:27:24 +0200, JM wrote:
> Hello
>
> Is there anybody who made has some experiences with ellipsis?
> I wrote the following code:
> ____
>
> void add_vals(string first_property_name, ...) {
>       var l = va_list();
>       print("\n1:\t%s-%s\n\t%s-%s\n\n",first_property_name,
>                  l.arg<string>(), l.arg<string>(), l.arg<string>());
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Unspecified order of evaluation here.

Function arguments may be evaluated in arbitrary order at compiler
discretion. It is that way in C and because of the way vala generates C code,
also in vala. Because of the way arguments are placed on the stack, the
compiler is likely to evaluate them last to first and that's what's happening
to you here. You'd have to write:

        var arg1 = l.arg<string>();
        var arg2 = l.arg<string>();
        var arg3 = l.arg<string>();

and than

        print(..., first_property_name, arg1, arg2, arg3);

to enforce the evaluation order.

>       add_vals_valist(first_property_name, l);

You are calling add_vals_valist like it was declared:

        void add_vals_valist(string first_property_name, va_list args)

> }
>
> void add_vals_valist(string first_property_name, ...) {
>       var l = va_list();

Therefore l contains *one* argument of type va_list!

>       print("\n2:\t%s-%s\n\t%s-%s\n\n", first_property_name, 
>                l.arg<string>(), l.arg<string>(), l.arg<string>());
> }
>
> static int main() {
>       add_vals(
>               "first",  "first_val",
>               "second", "second_val",
>               "3rd", "3rd_val",
>               null

Your function, despite being variadic, will always read exactly four string
arguments.

>       );
>       return 0;
> }
>
> ____
>
> It leads to the following output:
> $./ellipsis_forwarding 
>
> 1:    first-second_val
>       second-first_val

The compiler did indeed choose to evaluate the arguments last to first.
That's because the last arguments goes deepest in the stack (the other way
arount variable arguments would not be possible). It may decide to do it in
some other order at another time depending on what the optimizer evaluates as
best.

> [Invalid UTF-8] 
> 2:    first-second
>       (null)-\xea\x87\x04\x08\xe2\x87\x04\x08

The last part is result of interpreting the content of the va_args as string.
The rest is just arbitrary stuff from local variables of the calling
function, which happened to be sufficiently valid pointers not to crash the
program. If there was a non-pointer value there, you could have easily got
a segmentation fault.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>