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

           Summary: _argptr is char *
           Product: GDC
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: glue layer
        AssignedTo: dvdfrdmn@users.sf.net
        ReportedBy: akaquinn@hotmail.com


On DMD, _argptr is a void *, on GDC it's a char *. This is fairly minor, but I've ended up having to add casts for it in all sorts of code to make it compile on GDC. Because AFAIK there's no compelling reason for it to be a char * instead of a void *, I think it should be changed.

Yes, people should use std.stdarg's va_list ... but they don't X_X


-- 

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


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
           Keywords|                            |wrong-code




------- Comment #1 from smjg@iname.com  2007-09-17 20:56 -------
Please remember to assign keywords to bug reports.  To everybody reading this: Please look through issues you've reported and check for missing keywords.

It definitely should be changed:
- according to the spec, void* is the correct type of _argptr
- it makes no sense to assume that the data pointed to by it has character
semantics.


-- 

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





------- Comment #2 from afb@algonet.se  2007-09-18 01:38 -------
According to the spec, only DMD exists. It doesn't mention portability.

va_list is not a char* always, it's a "target-specific type". Don't cast. It needs the builtin va_list and the va_arg template for it to work...

I'm not sure how it could be rewritten to support DMD's direct access ? But David can probably give a much better explanation of the va_lists.


-- 

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





------- Comment #3 from smjg@iname.com  2007-09-18 07:07 -------
  (In reply to comment #2)
> According to the spec, only DMD exists. It doesn't mention portability.

Where is this bit of the spec that states that no other compiler exists?

> va_list is not a char* always, it's a "target-specific type". Don't cast. It needs the builtin va_list and the va_arg template for it to work...
std.stdarg, in DMD's implementation, defines va_list to be an alias of void*.
This is consistent with
http://www.digitalmars.com/d/function.html
- "These variadic functions have a special local variable declared for them,
_argptr, which is a void* pointer to the first of the variadic arguments."
- the code example on that page using std.stdarg

> I'm not sure how it could be rewritten to support DMD's direct access ? But David can probably give a much better explanation of the va_lists.

What do you mean by this?


-- 

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


larsivar@igesund.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |larsivar@igesund.net




------- Comment #4 from larsivar@igesund.net  2007-09-18 07:50 -------
(In reply to comment #2)
> According to the spec, only DMD exists. It doesn't mention portability.
> 
> va_list is not a char* always, it's a "target-specific type". Don't cast. It needs the builtin va_list and the va_arg template for it to work...
> 
> I'm not sure how it could be rewritten to support DMD's direct access ? But David can probably give a much better explanation of the va_lists.
> 

Considering that the target-specific type usually is based on some C specification, it is not particularly useful for D, as has been shown with Tango's use of indexing into the vararg list on platforms like x86_64. For this feature to be useful, it needs to be defined in a way that makes it portable, and afaik, David tries to fix this. The reason it wasn't implemented this way before, was that the C version already present in gcc was used.


-- 

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





------- Comment #5 from afb@algonet.se  2007-09-18 08:05 -------
(In reply to comment #3)

> > According to the spec, only DMD exists. It doesn't mention portability.
> 
> Where is this bit of the spec that states that no other compiler exists?

I'm just ticked that it's nigh impossible to add the predefined versions.

> > I'm not sure how it could be rewritten to support DMD's direct access ? But David can probably give a much better explanation of the va_lists.
> 
> What do you mean by this?

I'm not sure that std.c.stdarg can be done much better. But std.stdarg can probably be, as larsivi is mentioning. Especially for x86_64, it's needed.


-- 

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


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #6 from Walter Bright <bugzilla@digitalmars.com> 2010-11-08 16:12:09 PST ---
va_list is a void* on 64 bit targets, too. I originally had it as a pointer to that wacky struct required for the 64 bit C ABI, but it works better to treat it as a void*, and in the implementation of va_arg do the casting as necessary. This helps preserve encapsulation.

-- 
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=670



--- Comment #7 from Iain Buclaw <ibuclaw@ubuntu.com> 2011-01-16 06:45:15 PST ---
(In reply to comment #6)
> va_list is a void* on 64 bit targets, too. I originally had it as a pointer to that wacky struct required for the 64 bit C ABI, but it works better to treat it as a void*, and in the implementation of va_arg do the casting as necessary. This helps preserve encapsulation.

I'm currently at the point where I'm prototyping passing varargs in a packed structure (generated on the fly by the caller) on the stack. And using C varargs to get the address to assign to _argptr.


Think:

foo (parm, ...)
{
    va_start(__cargptr, parm);
    _argptr = va_arg(__cargptr, void*);
}

foo(&__argstruct);


So far it seems to be working well on 32bit architectures for simple datatypes...


Needs more testing though before I'd consider it fit for pushing out 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=670


Iain Buclaw <ibuclaw@ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #8 from Iain Buclaw <ibuclaw@ubuntu.com> 2011-03-27 07:35:26 PDT ---
https://bitbucket.org/goshawk/gdc/changeset/9a8cbe47da29 https://bitbucket.org/goshawk/gdc/changeset/521dce459f71#chg-d/d-builtins2.cc https://bitbucket.org/goshawk/gdc/changeset/d553b62db8e6#chg-d/d-builtins2.cc https://bitbucket.org/goshawk/gdc/changeset/ae8524183c6f

Required some nasty frontend hacks to trick the GCC backend into thinking it was dealing with a C ABI va_list type (and to not ICE it's way to Budapest and back), but pretty much done now.


- va_list treated is as void*
- __va_list is the C ABI va_list.


I'd not be too surprised if architectures where va_list is neither a pointer or array are broken now (such as ARM, where I'd imagine there'd be a nop cast from void* to struct) - but see how it goes when it hits the Debian repository...

Closing this report as fixed, and *don't* raise a bug about 64bit va_args, va_argsave, or whatever. As that ugly mess will never be implemented ( on my watch :)

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