Signed-off-by: Alistair Leslie-Hughes leslie_alistair@hotmail.com --- tools/widl/typetree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/widl/typetree.c b/tools/widl/typetree.c index dc4db35e835..aa8c302c064 100644 --- a/tools/widl/typetree.c +++ b/tools/widl/typetree.c @@ -226,10 +226,12 @@ static size_t append_type_signature(char **buf, size_t *len, size_t pos, type_t case TYPE_BASIC_DOUBLE: n += strappend(buf, len, pos + n, "f8"); return n; + case TYPE_BASIC_CHAR: + n += strappend(buf, len, pos + n, type_basic_get_sign(type) <= 0 ? "i1" : "u1"); + return n; case TYPE_BASIC_INT16: case TYPE_BASIC_INT3264: case TYPE_BASIC_LONG: - case TYPE_BASIC_CHAR: case TYPE_BASIC_HYPER: case TYPE_BASIC_BYTE: case TYPE_BASIC_WCHAR:
On 3/3/22 08:09, Alistair Leslie-Hughes wrote:
Signed-off-by: Alistair Leslie-Hughes leslie_alistair@hotmail.com
tools/widl/typetree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/widl/typetree.c b/tools/widl/typetree.c index dc4db35e835..aa8c302c064 100644 --- a/tools/widl/typetree.c +++ b/tools/widl/typetree.c @@ -226,10 +226,12 @@ static size_t append_type_signature(char **buf, size_t *len, size_t pos, type_t case TYPE_BASIC_DOUBLE: n += strappend(buf, len, pos + n, "f8"); return n;
case TYPE_BASIC_CHAR:
n += strappend(buf, len, pos + n, type_basic_get_sign(type) <= 0 ? "i1" : "u1");
return n; case TYPE_BASIC_INT16: case TYPE_BASIC_INT3264: case TYPE_BASIC_LONG:
case TYPE_BASIC_CHAR: case TYPE_BASIC_HYPER: case TYPE_BASIC_BYTE: case TYPE_BASIC_WCHAR:
Is this required for something specifically? I couldn't find any indication in the specification [1] how these would translate in the signatures.
[1] https://docs.microsoft.com/en-us/uwp/winrt-cref/winrt-type-system
Hi Remi,
Attached are the next two in the series that requires this one.
Maybe its the BYTE, that getting translated into to wrong type somewhere.
Regards Alistair
On 3/3/22 20:20, Rémi Bernon wrote:
On 3/3/22 08:09, Alistair Leslie-Hughes wrote:
Signed-off-by: Alistair Leslie-Hughes leslie_alistair@hotmail.com
tools/widl/typetree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/widl/typetree.c b/tools/widl/typetree.c index dc4db35e835..aa8c302c064 100644 --- a/tools/widl/typetree.c +++ b/tools/widl/typetree.c @@ -226,10 +226,12 @@ static size_t append_type_signature(char **buf, size_t *len, size_t pos, type_t case TYPE_BASIC_DOUBLE: n += strappend(buf, len, pos + n, "f8"); return n; + case TYPE_BASIC_CHAR: + n += strappend(buf, len, pos + n, type_basic_get_sign(type) <= 0 ? "i1" : "u1"); + return n; case TYPE_BASIC_INT16: case TYPE_BASIC_INT3264: case TYPE_BASIC_LONG: - case TYPE_BASIC_CHAR: case TYPE_BASIC_HYPER: case TYPE_BASIC_BYTE: case TYPE_BASIC_WCHAR:
Is this required for something specifically? I couldn't find any indication in the specification [1] how these would translate in the signatures.
[1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.micro...
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=109675
Your paranoid android.
=== debian11 (build log) ===
../wine/include/basetsd.h:82: error: unimplemented type signature for basic type 8. Task: The win32 Wine build failed
=== debian11 (build log) ===
../wine/include/basetsd.h:82: error: unimplemented type signature for basic type 8. Task: The wow64 Wine build failed
On 3/3/22 10:46, Alistair Leslie-Hughes wrote:
Hi Remi,
Attached are the next two in the series that requires this one.
Maybe its the BYTE, that getting translated into to wrong type somewhere.
Regards Alistair
Yes, it looks like BYTE should translate to u1 (and then maybe INT8 is incorrectly translated), and it also looks like it should:
1) be declared "typedef byte BYTE;", instead of "typedef unsigned char BYTE;" in wtypes.idl,
2) somehow be translated to lowercase "byte" in the type name mangling, otherwise they will all be incorrect.
Although for 2) it's not clear to me where this comes from. Other typedefed names keep their typedef names in the type name mangling. Maybe it's something builtin MIDL, would need a bit of investigation anyway.