On Wed, 9 Oct 2002, Brent Dax wrote:

> Can you try this?
> 
>       (at the top of the function...)
>       va_list *arg = (va_list *) & (obj->data);
>       (vararg accesses should look like...)
>       va_arg(*arg, ...);
>       (no end-of-function assignment should be necessary)
> 
> If that works for you, I'll commit a version that uses it.

That works for me, as does the simpler implicit cast
        va_arg(obj->data, ...);

Alas I fear neither one's going to work on PPC systems.  As Nicholas Clark
pointed out, va_list may be an opaque type, so that even innocent stuff
like misc.c's obj.data = args won't necessarily do what we want.

(I've redirected this back to p6i in case a PPC user is willing to
chip in and help out.)

Here's a relevant excerpt from my glibc stdarg() manpage:

va_copy
       An obvious implementation would have a va_list  a  pointer
       to  the  stack  frame of the variadic function.  In such a
       setup (by far the most common) there seems nothing against
       an assignment
                   va_list aq = ap;
       Unfortunately,  there  are  also  systems  that make it an
       array of pointers (of length 1), and there one needs
                   va_list aq;
                   *aq = *ap;
       Finally, on systems where parameters are passed in  regis
       ters, it may be necessary for va_start to allocate memory,
       store the parameters there,  and  also  an  indication  of
       which  parameter  is next, so that va_arg can step through
       the list. Now va_end can free the allocated memory  again.
       To  accommodate  this situation, C99 adds a macro va_copy,
       so that the above assignment can be replaced by
                   va_list aq;
                   va_copy(aq, ap);
                   ...
                   va_end(aq);

As I read the threads starting around
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-11/msg00803.html
(you have to follow both forward and backwards references to get the whole
story) the "array of pointers" approach is used on the PPC architecture,
so Parrot is definitely going to have to worry about running into this.

In light of this, I'm unsure how well your idea of a polymorphic obj->data
type is going to work out, though I realize that's a major feature of this
implementation.  But Sun's compiler's inability to handle the (va_list)
cast may well be the least of your worries :-).

-- 
    Andy Dougherty              [EMAIL PROTECTED]


Reply via email to