Bug 13125 – Cannot implicitly convert string* to __va_list_tag*

This code compiled in DMD 2.065.0 but fails in DMD 2.066.0-b3: import core.vararg; void main () { string a; core.vararg.va_list b = &a; } The error message is: "Error: cannot implicitly convert expression (& a) of type string* to __va_list_tag*". This is from DWT [1] and [2]. [1] https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L81 [2] https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L385

The trouble is that va_list was a void* in 2.065, but is now a magic type that is handled specially by the back end. Doing what you're doing in this code is really not supportable. I'm not sure what dwt is doing there, so don't have an immediate suggested fix.

(In reply to Walter Bright from comment #1) > Doing what you're doing in this code is really not supportable. Yeah, the code looks suspicious. > I'm not sure what dwt is doing there, so don't have an immediate suggested > fix. I think the intention is to forward the varargs of "trace" [1] to "doVarArgFormat" [2], but first prepend the "fmt" argument to the varargs. [1] https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L79 [2] https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L385

I also seriously doubt that DWT code actually worked on 2.065 on Posix 64 bits, even though it compiled.

(In reply to Walter Bright from comment #3) > I also seriously doubt that DWT code actually worked on 2.065 on Posix 64 > bits, even though it compiled. It doesn't support 64bit yet.

(In reply to Jacob Carlborg from comment #4) > (In reply to Walter Bright from comment #3) > > I also seriously doubt that DWT code actually worked on 2.065 on Posix 64 > > bits, even though it compiled. > > It doesn't support 64bit yet. This current problem should only appear on 64 bits, and only on posix systems. How did you run into it?

I'm going to resolve this as invalid because: 1. I'm pretty sure it never did work, even if it compiled. va_list doesn't work that way. At least now the compiler flags that this construct won't work. 2. va_list is magic on Posix 64, and this is allowed by the C Standard. We can't make the compiler make this work and be compliant with C varargs. 3. What DWT is doing is not the right way to do things with va_list. 4. DWT will need work to port it to 64 bits, as it never has yet run on 64.

(In reply to Walter Bright from comment #5) > This current problem should only appear on 64 bits, and only on posix > systems. How did you run into it? I actually found this on Linux 32bit when compiling DWT. I got the same error on OS X 64bit from which the error message is from. I think it was "char*" instead of "__va_list_tag*" on Linux 32bit. I didn't think it mattered since I got the exact error message but with different types.

(In reply to Walter Bright from comment #6) > I'm going to resolve this as invalid because: > > 1. I'm pretty sure it never did work, even if it compiled. va_list doesn't > work that way. At least now the compiler flags that this construct won't > work. I'm pretty sure it does work. I think it's an misunderstanding due to the error message I reported. I found this issue first on Linux 32bit and the reproduced it on OS X 64bit where the error message is from. > 2. va_list is magic on Posix 64, and this is allowed by the C Standard. We > can't make the compiler make this work and be compliant with C varargs. > > 3. What DWT is doing is not the right way to do things with va_list. > > 4. DWT will need work to port it to 64 bits, as it never has yet run on 64. It's my fault for creating the report this way, I thought the platform didn't matter. This is on Linux 32bit. Any way. Do you have a suggestion for a workaround? What is the appropriate way to forward varargs?

(In reply to Walter Bright from comment #1) > The trouble is that va_list was a void* in 2.065, but is now a magic type > that is handled specially by the back end. Doing what you're doing in this > code is really not supportable. > It's not actually a magic backend-known type, but it is platform dependent. (In reply to Jacob Carlborg from comment #8) > > Any way. Do you have a suggestion for a workaround? What is the appropriate > way to forward varargs? As far as I know there is not supported way to hack into varargs like this. As an awful non-portable self-destructive workaround you can use an explicit cast to get the old behaviour. To do this correctly, you will need to research the various platforms' varargs formats and explicitly match them. If possible I would recommend using a different implementation approach.

(In reply to yebblies from comment #9) > As far as I know there is not supported way to hack into varargs like this. > As an awful non-portable self-destructive workaround you can use an explicit > cast to get the old behaviour. > > To do this correctly, you will need to research the various platforms' > varargs formats and explicitly match them. If possible I would recommend > using a different implementation approach. Ok, I'll see if I can come up with something else.