www.digitalmars.com         C & C++   DMDScript  

D.gnu - [Issue 670] New: _argptr is char *

reply d-bugmail puremagic.com writes:
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


--
Dec 09 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670


smjg iname.com changed:

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





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.


--
Sep 17 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670






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.


--
Sep 17 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670








 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?


--
Sep 18 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670


larsivar igesund.net changed:

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







 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.


--
Sep 18 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670









 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.


--
Sep 18 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670


Walter Bright <bugzilla digitalmars.com> changed:

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



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: -------
Nov 08 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670






 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: -------
Jan 16 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=670


Iain Buclaw <ibuclaw ubuntu.com> changed:

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



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: -------
Mar 27 2011