Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h
Hi Michael, On 10/26/11 00:30, Michael Stefaniuc wrote:
--- include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- 1 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/include/d3d9caps.h b/include/d3d9caps.h index 8ed6598..64dba21 100644 --- a/include/d3d9caps.h +++ b/include/d3d9caps.h @@ -29,13 +29,13 @@ #define D3DCURSORCAPS_LOWRES 2
-#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040
mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Thanks, Jacek
Hello Jacek! Jacek Caban wrote:
On 10/26/11 00:30, Michael Stefaniuc wrote:
--- include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- 1 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/include/d3d9caps.h b/include/d3d9caps.h index 8ed6598..64dba21 100644 --- a/include/d3d9caps.h +++ b/include/d3d9caps.h @@ -29,13 +29,13 @@ #define D3DCURSORCAPS_LOWRES 2
-#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040
mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Well ... the the dinput.h was a real change were Wine was affected. But the change should be mostly harmless for mingw-w64 as long == int on Win32 and Win64.
Anyway this is a hit job from Alexandre so you'll have to convince him. bye michael
2011/10/26 Michael Stefaniuc <mstefani(a)redhat.com>:
Hello Jacek!
Jacek Caban wrote:
On 10/26/11 00:30, Michael Stefaniuc wrote:
--- include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- 1 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/include/d3d9caps.h b/include/d3d9caps.h index 8ed6598..64dba21 100644 --- a/include/d3d9caps.h +++ b/include/d3d9caps.h @@ -29,13 +29,13 @@ #define D3DCURSORCAPS_LOWRES 2
-#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040
mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Well ... the the dinput.h was a real change were Wine was affected. But the change should be mostly harmless for mingw-w64 as long == int on Win32 and Win64.
Anyway this is a hit job from Alexandre so you'll have to convince him.
bye michael
Hi Michael, 2011/10/26 Jacek Caban <jacek(a)codeweavers.com>:
Hi Michael,
On 10/26/11 00:30, Michael Stefaniuc wrote:
--- include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- 1 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/include/d3d9caps.h b/include/d3d9caps.h index 8ed6598..64dba21 100644 --- a/include/d3d9caps.h +++ b/include/d3d9caps.h @@ -29,13 +29,13 @@ #define D3DCURSORCAPS_LOWRES 2
-#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040
mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it?
Thanks, Jacek
As Jacek mentioned already, it would be for our use of Wine direct-x SDK a big flaw to have constants here not proper suffixed with L. Especially in use for C++ this would cause big pain for 32-bit and 64-bit native Windows compilation. I am not sure about this, but I assume that Wine might have an interest to be able to use platform-headers and optional SDKs also with a cross-compiler targeting for Windows native. I would suggest to use here a helper-macro, which does on demand the required L-suffix. Something like in global configure headers: #ifdef __SIZEOF_LONG <= 32 #define MSABI_LONG(VAL) VAL ## L #else #define MSABI_LONG(VAL) VAL #endif And then using in platform/sdk headers ... #define XYZ MSABI_LONG(0x1234) ... instead. Regards, Kai
On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote:
Hello Jacek!
Jacek Caban wrote:
mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it?
Well ... the the dinput.h was a real change were Wine was affected. But the change should be mostly harmless for mingw-w64 as long == int on Win32 and Win64.
The compiler does still complain about types even if the type is the same size. Such as when using printf formatting (%x = int, #lx = long; GCC complains if the type doesn't match, even if it's the same size). Also I could imagine some C++ function overrides tripping up with the int/long difference.
Chris Robinson wrote:
On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote:
Hello Jacek!
Jacek Caban wrote:
mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Well ... the the dinput.h was a real change were Wine was affected. But the change should be mostly harmless for mingw-w64 as long == int on Win32 and Win64.
The compiler does still complain about types even if the type is the same size. Such as when using printf formatting (%x = int, #lx = long; GCC complains if the type doesn't match, even if it's the same size). Also I could Right, one of the reasons we do this change for Wine.
imagine some C++ function overrides tripping up with the int/long difference. If you use the Wine headers this should actually fix it as it brings the numeric constants in line with the types as LONG == int in Wine.
bye michael
On Wednesday, October 26, 2011 12:35:28 PM Michael Stefaniuc wrote:
Chris Robinson wrote:
imagine some C++ function overrides tripping up with the int/long difference. If you use the Wine headers this should actually fix it as it brings the numeric constants in line with the types as LONG == int in Wine.
For Wine it doesn't really matter, since we can't use C++. For mingw-w64, however, it could be a big problem if it's not properly typed as a long. Overloads and template types would silently use 'int' where it should be using 'long', and you wouldn't necessarily know until you see odd behavior in the app.
Chris Robinson <chris.kcat(a)gmail.com> wrote:
For Wine it doesn't really matter, since we can't use C++. For mingw-w64, however, it could be a big problem if it's not properly typed as a long. Overloads and template types would silently use 'int' where it should be using 'long', and you wouldn't necessarily know until you see odd behavior in the app.
What kind of odd behaviour? Both int and long are 32-bit in win32 and win64. -- Dmitry.
2011/10/26 Dmitry Timoshkov <dmitry(a)baikal.ru>:
Chris Robinson <chris.kcat(a)gmail.com> wrote:
For Wine it doesn't really matter, since we can't use C++. For mingw-w64, however, it could be a big problem if it's not properly typed as a long. Overloads and template types would silently use 'int' where it should be using 'long', and you wouldn't necessarily know until you see odd behavior in the app.
What kind of odd behaviour? Both int and long are 32-bit in win32 and win64.
-- Dmitry.
See as example for C++: #include <stdio.h> void foo (int i) { printf ("int i == %d\n", i); } void foo (long i) { printf ("long i == %ld\n", i); } int main () { foo (1); foo (1L); return 0; } if you compile this program and execute it, then you will see the following output: $ ./tst.exe int i == 1 long i == 1 C++ has the ability to have for same function name different implementation for different argument types. Means, argument types getting part of function's signature. So you might see the cause what is different about suffixed/non-suffixed values for C++. Regards, Kai
participants (5)
-
Chris Robinson -
Dmitry Timoshkov -
Jacek Caban -
Kai Tietz -
Michael Stefaniuc