Re: Problem with new stdarg implementation (gcc >= 2.9x)

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Bruno Haible]

> What I ask for is an interface that allows pass a size instead of a tag
> and parse it this way:
>
>     size = va_arg(ap, size);
>     memcpy(datum, va_arg(ap, typeof(structofsize(size)), size);

It is impossible. Take for example mips in 64-bit mode. doubles inside
a structure are passed in floating point registers, not in integer registers.
If you only pass the size and alignment of the structure, the va_arg
macro will not be able to distinguish
  struct { double x; }
and
  struct { long x; }
and you will therefore get wrong results.

If you restrict yourself to structures which only contain `long' or `void*'
items, you can solve the problem by treating each CPU and ABI, one by one.
This approach has been realized in [1]. But beware: it is far from portable.

                   Bruno

[1] ftp://ftp.santafe.edu/pub/gnu/ffcall-1.6.tar.gz

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri Pudgorodsky]

Bruno Haible wrote:

> > What I ask for is an interface that allows pass a size instead of a tag
> > and parse it this way:
> >
> >     size = va_arg(ap, size);
> >     memcpy(datum, va_arg(ap, typeof(structofsize(size)), size);
>
> It is impossible. Take for example mips in 64-bit mode. doubles inside
> a structure are passed in floating point registers, not in integer registers.
> If you only pass the size and alignment of the structure, the va_arg
> macro will not be able to distinguish
>   struct { double x; }
> and
>   struct { long x; }
> and you will therefore get wrong results.

Well it is a very disappointing news...

But I'm interesting, does va_arg() handle it with full type info
given - va_arg(ap, struct mystruct)?

Also, will the following code correctly compile on this plarform?

void foo(struct struct_with_double)
{
    memcpy(&another_such_struct, &struct_with_double, sizeof(struct_with_double));
    bar(&struct_with_double);
}

And you mentioned phrase "not in interger registers". Does it mean compiler
pass some function arguments in integer registers? Is this portable?
How many platforms do it by default?

I supposed that passing arguments in registers instead of stack is a compilers
extension that break standart ABI on many platforms.

May be you mean passing the return values?

Thanks,
Yuri Pudgorodsky

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Richard Henderson]

On Sat, Oct 23, 1999 at 10:13:40AM +0400, Yuri Pudgorodsky wrote:
> But I'm interesting, does va_arg() handle it with full type info
> given - va_arg(ap, struct mystruct)?

Yes.

> And you mentioned phrase "not in interger registers". Does it mean compiler
> pass some function arguments in integer registers?

Yes.

> Is this portable?

What has portability got to do with processor-specific conventions?

> How many platforms do it by default?

Almost all.  x86 is a notable exception.

> I supposed that passing arguments in registers instead of stack is a
> compilers extension that break standart ABI on many platforms.

Just the opposite -- the standard ABI on most platforms _is_
to pass arguments in integer and/or floating point registers.


r~

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri Pudgorodsky]

Bruno Haible wrote:

> > What I ask for is an interface that allows pass a size instead of a tag
> > and parse it this way:
> >
> >     size = va_arg(ap, size);
> >     memcpy(datum, va_arg(ap, typeof(structofsize(size)), size);
>
> It is impossible. Take for example mips in 64-bit mode. doubles inside
> a structure are passed in floating point registers, not in integer registers.
> If you only pass the size and alignment of the structure, the va_arg
> macro will not be able to distinguish
>   struct { double x; }
> and
>   struct { long x; }
> and you will therefore get wrong results.

Well it is a very disappointing news...

But I'm interesting, does va_arg() handle it with full type info
given - va_arg(ap, struct mystruct)?

Also, will the following code correctly compile on this plarform?

void foo(struct struct_with_double)
{
    memcpy(&another_such_struct, &struct_with_double, sizeof(struct_with_double));
    bar(&struct_with_double);
}

And you mentioned phrase "not in interger registers". Does it mean compiler
pass some function arguments in integer registers? Is this portable?
How many platforms do it by default?

I supposed that passing arguments in registers instead of stack is a compilers
extension that break standart ABI on many platforms.

May be you mean passing the return values?

Thanks,
Yuri Pudgorodsky

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Richard Henderson]

On Sat, Oct 23, 1999 at 10:13:40AM +0400, Yuri Pudgorodsky wrote:
> But I'm interesting, does va_arg() handle it with full type info
> given - va_arg(ap, struct mystruct)?

Yes.

> And you mentioned phrase "not in interger registers". Does it mean compiler
> pass some function arguments in integer registers?

Yes.

> Is this portable?

What has portability got to do with processor-specific conventions?

> How many platforms do it by default?

Almost all.  x86 is a notable exception.

> I supposed that passing arguments in registers instead of stack is a
> compilers extension that break standart ABI on many platforms.

Just the opposite -- the standard ABI on most platforms _is_
to pass arguments in integer and/or floating point registers.


r~

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Bruno Haible]

> What I ask for is an interface that allows pass a size instead of a tag
> and parse it this way:
>
>     size = va_arg(ap, size);
>     memcpy(datum, va_arg(ap, typeof(structofsize(size)), size);

It is impossible. Take for example mips in 64-bit mode. doubles inside
a structure are passed in floating point registers, not in integer registers.
If you only pass the size and alignment of the structure, the va_arg
macro will not be able to distinguish
  struct { double x; }
and
  struct { long x; }
and you will therefore get wrong results.

If you restrict yourself to structures which only contain `long' or `void*'
items, you can solve the problem by treating each CPU and ABI, one by one.
This approach has been realized in [1]. But beware: it is far from portable.

                   Bruno

[1] ftp://ftp.santafe.edu/pub/gnu/ffcall-1.6.tar.gz

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Richard Henderson]

On Thu, Oct 21, 1999 at 10:15:30PM +0400, Yuri Pudgorodsky wrote:
> With current implementation I do not.
> But it was possible with the old stdarg, and I ask you people for reasons,
> does it make sense to restore the previous behavior just for this case.
> 
> Arguments for it:

Arguments against it:

  Variable sized structures cannot be passed through (...)
  on any ABI that changes the location of passed data based
  on the data's size.

You happened to stumble on to a construction that happened
to work on x86, and a couple of other targets.  It did not 
work on ppc-svr4, mips-irix6, sparc64, and many others.

> I mean take some implementation and make it portable across platforms
> we need/support.

Pass by reference then.

> You do not say that passing struct by value as an argument is not
> portable, do you?

Struct has a fixed size.  That is a different problem.



r~

Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri Pudgorodsky]

Older gcc (egcs 1.1.2) permits constuction like that

#include <stdarg.h>
#include <string.h>

char datum[256];
void func(int size, ...) {
    va_list ap;
    va_start (ap, size);
    memcpy(datum, va_arg(ap, typeof(char[size])), size);
}

int main () {
    struct { double d; int i; } value = { 3.14, 100 };
    func(sizeof(value), value);
}

The newer gcc (at least 2.96-snapshots, I did not check 2.95.x)
has a different stdarg implementation. So for now the program has
been rejects with the error:"invalid use of non-lvalue array".

I cannot find a workaround, how can someone code the same task:
takes a variable-sized structure passed by value from a
function with (...). I have the only idea for today: throw away
gcc's builtin stdarg implementation, and use some old portable
C-only implementation to traverse ap manually.

This sounds unnecessary complex, have you other ideas?

BTW this technique is in use inside GNUstep Foundation library
(www.gnustep.org), to store method selector and arguments
for later invocation on different target.

It will not good, if the GNUstep cannot use the latest GCC.


Thank you,
Yuri Pudgorodsky

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri Pudgorodsky]

Richard Henderson wrote:

> On Thu, Oct 21, 1999 at 02:21:49PM +0400, Yuri Pudgorodsky wrote:
> >     memcpy(datum, va_arg(ap, typeof(char[size])), size);
>
> What exactly did you think this was doing?  It's not
> surprising at all that it doesn't do what you think.

It would be great if it will work in the same way as it was with
the previous implementation:

char * p = va_arg(ap, typeof(char[size]))

 is translated into

p = address of the first element of the array located at ap.
ap =  ap (+ or -) sizeof typeof(char[size])

I argue you with the same behavior of explicitly declared array:

char data[size];           // typeof (data) == typeof(char[size])
char * p = data;           // va_arg() should return the same value as
                              an assigment of the value of the specified type
char * ap += sizeof(data); // ap should be skipped to the next arg in the frame

In case of arrays the value is its address of the first item,
and its size is the size of the overall items.


> > I cannot find a workaround, how can someone code the same task:
> > takes a variable-sized structure passed by value from a
> > function with (...).
>
> You don't.

With current implementation I do not.
But it was possible with the old stdarg, and I ask you people for reasons,
does it make sense to restore the previous behavior just for this case.

Arguments for it:
- it has a reasonably intuitive sematic;
- it previously had the described semantic;
- it helps copy structures passed by value out of va_args frame:
   not so strange idea if you deal with a run-time for some dynamically bound
   language extensions;
- if supported by the compiler, the solution will be portable across all
   platforms the compiler support;
- typeof is already a GCC extension, why not to extend it in this way.

> > I have the only idea for today: throw away
> > gcc's builtin stdarg implementation, and use some old portable
> > C-only implementation to traverse ap manually.
>
> There is no portable implementation.  Period.

I mean take some implementation and make it portable across platforms we need/support.
BTW typeof() construct itself is not portable outside gcc.

> The only portable way to pass a variable amount of data is to
> pass it by reference and make a copy in the callee (if needed).

You do not say that passing struct by value as an argument is not
portable, do you? Why should we restrict this usage for functions
with eclipses?


Regards,
Yuri Pudgorodsky

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Richard Henderson]

On Thu, Oct 21, 1999 at 02:21:49PM +0400, Yuri Pudgorodsky wrote:
>     memcpy(datum, va_arg(ap, typeof(char[size])), size);

What exactly did you think this was doing?  It's not
surprising at all that it doesn't do what you think.

> I cannot find a workaround, how can someone code the same task:
> takes a variable-sized structure passed by value from a
> function with (...).

You don't.

> I have the only idea for today: throw away
> gcc's builtin stdarg implementation, and use some old portable
> C-only implementation to traverse ap manually.

There is no portable implementation.  Period.

The only portable way to pass a variable amount of data is to
pass it by reference and make a copy in the callee (if needed).


r~

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri A. Pudgorodsky]

Richard Henderson wrote:

> On Thu, Oct 21, 1999 at 10:15:30PM +0400, Yuri Pudgorodsky wrote:
> > With current implementation I do not.
> > But it was possible with the old stdarg, and I ask you people for reasons,
> > does it make sense to restore the previous behavior just for this case.
> >
> > Arguments for it:
>
> Arguments against it:
>
>   Variable sized structures cannot be passed through (...)
>   on any ABI that changes the location of passed data based
>   on the data's size.
>
> You happened to stumble on to a construction that happened
> to work on x86, and a couple of other targets.  It did not
> work on ppc-svr4, mips-irix6, sparc64, and many others.
>
> > I mean take some implementation and make it portable across platforms
> > we need/support.
>
> Pass by reference then.
>
> > You do not say that passing struct by value as an argument is not
> > portable, do you?
>
> Struct has a fixed size.  That is a different problem.

We are able to pass some structures of different sizes among with tag
to (...) and when parse it like:

    tag = va_arg(ap, int);
    switch (tag) {
        case TYPE1: memcpy(datum, va_arg(ap, struct st1), sizeof(struct st1)); break;
        case TYPE2: memcpy(datum, va_arg(ap, struct st2), sizeof(struct st2)); break;
        ...
    }

I suppose the above code is completele portable for any ABI.

What I ask for is an interface that allows pass a size instead of a tag and parse it this way:

    size = va_arg(ap, size);
    memcpy(datum, va_arg(ap, typeof(structofsize(size)), size);

Usage of typeof(char[size]) looks to me like a suitable syntax.
With them we have size information for va_arg() and may correct
ap location based on this data size. Also, va_arg should return
the address of the first data byte, by analogue with arrays behavior.

Is it difficult or impossible? Where am I wrong?

Yuri Pudgorodsky

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri A. Pudgorodsky]

Richard Henderson wrote:

> On Thu, Oct 21, 1999 at 10:15:30PM +0400, Yuri Pudgorodsky wrote:
> > With current implementation I do not.
> > But it was possible with the old stdarg, and I ask you people for reasons,
> > does it make sense to restore the previous behavior just for this case.
> >
> > Arguments for it:
>
> Arguments against it:
>
>   Variable sized structures cannot be passed through (...)
>   on any ABI that changes the location of passed data based
>   on the data's size.
>
> You happened to stumble on to a construction that happened
> to work on x86, and a couple of other targets.  It did not
> work on ppc-svr4, mips-irix6, sparc64, and many others.
>
> > I mean take some implementation and make it portable across platforms
> > we need/support.
>
> Pass by reference then.
>
> > You do not say that passing struct by value as an argument is not
> > portable, do you?
>
> Struct has a fixed size.  That is a different problem.

We are able to pass some structures of different sizes among with tag
to (...) and when parse it like:

    tag = va_arg(ap, int);
    switch (tag) {
        case TYPE1: memcpy(datum, va_arg(ap, struct st1), sizeof(struct st1)); break;
        case TYPE2: memcpy(datum, va_arg(ap, struct st2), sizeof(struct st2)); break;
        ...
    }

I suppose the above code is completele portable for any ABI.

What I ask for is an interface that allows pass a size instead of a tag and parse it this way:

    size = va_arg(ap, size);
    memcpy(datum, va_arg(ap, typeof(structofsize(size)), size);

Usage of typeof(char[size]) looks to me like a suitable syntax.
With them we have size information for va_arg() and may correct
ap location based on this data size. Also, va_arg should return
the address of the first data byte, by analogue with arrays behavior.

Is it difficult or impossible? Where am I wrong?

Yuri Pudgorodsky

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Richard Henderson]

On Thu, Oct 21, 1999 at 10:15:30PM +0400, Yuri Pudgorodsky wrote:
> With current implementation I do not.
> But it was possible with the old stdarg, and I ask you people for reasons,
> does it make sense to restore the previous behavior just for this case.
> 
> Arguments for it:

Arguments against it:

  Variable sized structures cannot be passed through (...)
  on any ABI that changes the location of passed data based
  on the data's size.

You happened to stumble on to a construction that happened
to work on x86, and a couple of other targets.  It did not 
work on ppc-svr4, mips-irix6, sparc64, and many others.

> I mean take some implementation and make it portable across platforms
> we need/support.

Pass by reference then.

> You do not say that passing struct by value as an argument is not
> portable, do you?

Struct has a fixed size.  That is a different problem.



r~

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri Pudgorodsky]

Richard Henderson wrote:

> On Thu, Oct 21, 1999 at 02:21:49PM +0400, Yuri Pudgorodsky wrote:
> >     memcpy(datum, va_arg(ap, typeof(char[size])), size);
>
> What exactly did you think this was doing?  It's not
> surprising at all that it doesn't do what you think.

It would be great if it will work in the same way as it was with
the previous implementation:

char * p = va_arg(ap, typeof(char[size]))

 is translated into

p = address of the first element of the array located at ap.
ap =  ap (+ or -) sizeof typeof(char[size])

I argue you with the same behavior of explicitly declared array:

char data[size];           // typeof (data) == typeof(char[size])
char * p = data;           // va_arg() should return the same value as
                              an assigment of the value of the specified type
char * ap += sizeof(data); // ap should be skipped to the next arg in the frame

In case of arrays the value is its address of the first item,
and its size is the size of the overall items.


> > I cannot find a workaround, how can someone code the same task:
> > takes a variable-sized structure passed by value from a
> > function with (...).
>
> You don't.

With current implementation I do not.
But it was possible with the old stdarg, and I ask you people for reasons,
does it make sense to restore the previous behavior just for this case.

Arguments for it:
- it has a reasonably intuitive sematic;
- it previously had the described semantic;
- it helps copy structures passed by value out of va_args frame:
   not so strange idea if you deal with a run-time for some dynamically bound
   language extensions;
- if supported by the compiler, the solution will be portable across all
   platforms the compiler support;
- typeof is already a GCC extension, why not to extend it in this way.

> > I have the only idea for today: throw away
> > gcc's builtin stdarg implementation, and use some old portable
> > C-only implementation to traverse ap manually.
>
> There is no portable implementation.  Period.

I mean take some implementation and make it portable across platforms we need/support.
BTW typeof() construct itself is not portable outside gcc.

> The only portable way to pass a variable amount of data is to
> pass it by reference and make a copy in the callee (if needed).

You do not say that passing struct by value as an argument is not
portable, do you? Why should we restrict this usage for functions
with eclipses?


Regards,
Yuri Pudgorodsky

Re: Problem with new stdarg implementation (gcc >= 2.9x)

[Richard Henderson]

On Thu, Oct 21, 1999 at 02:21:49PM +0400, Yuri Pudgorodsky wrote:
>     memcpy(datum, va_arg(ap, typeof(char[size])), size);

What exactly did you think this was doing?  It's not
surprising at all that it doesn't do what you think.

> I cannot find a workaround, how can someone code the same task:
> takes a variable-sized structure passed by value from a
> function with (...).

You don't.

> I have the only idea for today: throw away
> gcc's builtin stdarg implementation, and use some old portable
> C-only implementation to traverse ap manually.

There is no portable implementation.  Period.

The only portable way to pass a variable amount of data is to
pass it by reference and make a copy in the callee (if needed).


r~

Problem with new stdarg implementation (gcc >= 2.9x)

[Yuri Pudgorodsky]

Older gcc (egcs 1.1.2) permits constuction like that

#include <stdarg.h>
#include <string.h>

char datum[256];
void func(int size, ...) {
    va_list ap;
    va_start (ap, size);
    memcpy(datum, va_arg(ap, typeof(char[size])), size);
}

int main () {
    struct { double d; int i; } value = { 3.14, 100 };
    func(sizeof(value), value);
}

The newer gcc (at least 2.96-snapshots, I did not check 2.95.x)
has a different stdarg implementation. So for now the program has
been rejects with the error:"invalid use of non-lvalue array".

I cannot find a workaround, how can someone code the same task:
takes a variable-sized structure passed by value from a
function with (...). I have the only idea for today: throw away
gcc's builtin stdarg implementation, and use some old portable
C-only implementation to traverse ap manually.

This sounds unnecessary complex, have you other ideas?

BTW this technique is in use inside GNUstep Foundation library
(www.gnustep.org), to store method selector and arguments
for later invocation on different target.

It will not good, if the GNUstep cannot use the latest GCC.


Thank you,
Yuri Pudgorodsky