http://d.puremagic.com/issues/show_bug.cgi?id=4172

           Summary: Improve varargs
           Product: D
           Version: future
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: nfxjfg@gmail.com


--- Comment #0 from nfxjfg@gmail.com 2010-05-10 13:43:40 PDT ---
Right now, "D-style Variadic Functions" provide _argptr and _arguments "magic" variables. _argptr is just a pointer to the arguments, and getting the pointer to each actual argument is very hard to implement. Actually it's _impossible_ to do in a portable way. Think of non-x86 architectures.

I propose the introduction of an additional _argarray variable, which is a void*[]. Each array item should point to an argument's value, similar how each item of _arguments contains the type of the argument.

Example:

void foo(...) {
   for (uint i = 0; i < _arguments.length; i++) {
     writefln("type of argument %s: %s", i, _arguments[i]);
     writefln("pointer to argument %s: %s", i, _argarray[i]);
   }
}

(Try that with to implement in a portable way without _argarray!)

This would also allow to implement positional format arguments more easily.

Note that there's the va_arg template, but it only works with argument types known at compile time. For formatting functions and the like, you want to be able to do everything at runtime.

This proposal is meant for both D1 and D2.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172


Fawzi Mohamed <fawzi@gmx.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fawzi@gmx.ch


--- Comment #1 from Fawzi Mohamed <fawzi@gmx.ch> 2010-11-24 15:24:32 PST ---
The clean way to fix this (and what LDC does) is to pack all arguments (aligning them) in a stack allocated array, create the typeinfo array, and then call the function passing to it a void* to the packed array and the typeinfo array.

Thus the D vararg would be equivalent to void*,TypeInfo[].
More explicitly
f(...) -> f(void*,TypeInfo[])

This is slightly less efficient than C for some arguments, but is very portable, and one can skip an argument just using typeinfo information (tsize, and possibly alignment).

This was the first bug I did encounter when coming to D: I did try to print a complex number and it failed because tango did not explicitly decode a complex. I did add support for some more kinds of hard coded structs to decode, but as nfxjfg says it is impossible to cover all cases on all architectures, as one should cover all possible types at compile time and decode each one with a special va_arg call.

The proposed solution is relatively efficient, and portable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #2 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-11-25 22:08:23 PST ---
(In reply to comment #1)
> The clean way to fix this (and what LDC does) is to pack all arguments (aligning them) in a stack allocated array, create the typeinfo array, and then call the function passing to it a void* to the packed array and the typeinfo array.

Doesn't dmd do the same?

More handy way is to pack arguments into struct and pass single TypeInfo for that struct. It already has all necessary align and offset info there.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #3 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-11-25 22:11:11 PST ---
And TypeInfo is immutable and doesn't require construction on every call.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #4 from nfxjfg@gmail.com 2010-11-26 01:00:56 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > The clean way to fix this (and what LDC does) is to pack all arguments (aligning them) in a stack allocated array, create the typeinfo array, and then call the function passing to it a void* to the packed array and the typeinfo array.
> 
> Doesn't dmd do the same?

Yeah, it looks like dmd on 64 bit will emulate the old shitty way that was "natural" for dmd on 32 bit. But I don't understand why you would WANT to do that. Why emulate something broken and hard to use? Passing an array of void* to each parameter (see _argarray in issue description) would be so much easier.

> More handy way is to pack arguments into struct and pass single TypeInfo for that struct. It already has all necessary align and offset info there.

Not sure what you mean by that. There's no RTTI for struct members, so this would be very not-useful. You'd still need to pass _arguments, and you'd still need to follow the ABI for the struct layout (granted, better than trying to follow the stack layout).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #5 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-11-26 10:43:31 PST ---
TypeInfo has offTi property that returns OffsetTypeInfo[], which is exactly what you want - types and offsets of struct members.

What problem do you have with struct layout? You can't sum address of struct and field offset to get address of field? Anyway, if reflection in D is awful, may be it's better to make it usable rather than burden the compiler with work that can be done by reflection but is not done yet?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #6 from nfxjfg@gmail.com 2010-11-26 14:15:36 PST ---
(In reply to comment #5)
> TypeInfo has offTi property that returns OffsetTypeInfo[], which is exactly what you want - types and offsets of struct members.

That information is (and always has been) missing. offTi is always null. Maybe Walter tried it and then thought it'd use too much memory.

> What problem do you have with struct layout? You can't sum address of struct and field offset to get address of field? Anyway, if reflection in D is awful, may be it's better to make it usable rather than burden the compiler with work that can be done by reflection but is not done yet?

Good luck with that. And I don't see any additional burden. It's already burdened with "packing" the params on the stack. My proposal might actually make it simpler for both compiler and user. Why burden the user with highly ABI dependent struct or stack layouts? Is this assembler?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei@metalanguage.com
            Version|future                      |D1
         AssignedTo|nobody@puremagic.com        |bugzilla@digitalmars.com


--- Comment #7 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-11-28 09:32:53 PST ---
Marking this as a D1 only thing and leaving decision to Walter. My suggestion is to close this as a wontfix.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #8 from Fawzi Mohamed <fawzi@gmx.ch> 2010-11-28 12:53:12 PST ---
I agree, I came to this from  a discussion on the IRC, and I was thinking it
was a GDC bug (which has a badly broken implementation.
If implemented correctly, and with alignment info and size in the typeinfo it
is perfectly workable.
Not the most nice possible, but reasonably efficient and usable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4172



--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2010-11-29 21:56:33 PST ---
Unfortunately, the 64 bit C ABI is rather disastrously complex for varargs. I went back and forth for a while on how to implement it, and whether to use the C ABI for D variadic functions as well as C variadic functions.

I finally decided that, although the C variadics were inefficient, they are used rarely enough that it doesn't much matter, and that D will follow the C ABI.

The result is a much expanded and more complex std.c.stdarg implementation.

We can revisit this and look into making it more efficient later, but for now I just want to get it working.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------