Signed-off-by: Jacek Caban jacek@codeweavers.com ---
Right now we use _MSC_VER to choose between long and int type. We could, however, make any other choice. With patch 1, it's possible to use int with MSVC (or at least clang MSVC target). It's also possible for any other compilers except __LP64__ to use long.
This raises some questions and I wouldn't mind changing the patch. For example, I could change headers to always use int. The problem with that is that it makes us incompatible with the rest of Windows world.
In the past, the choice of int for LONG was motivated by port to Win64, where we can't use long on UNIX side and it's nice to have the same time on all targets.
This patch is a compromise: it always uses int for Wine itself, so as far as building Wine is considered, it's consistent among compilers. Outside Wine, it uses long on Windows targets, where the code is most likely to depend on underlying type. And it keeps using int for non-Windows targets, so nothing changes for non-PE winelib.
If there is a need for int LONG on Windows targets, we could introduce a macro to change that choice. I could also imagine revisiting the choice for PE parts of Wine itself, but it would be a lot of work.
include/guiddef.h | 2 +- include/ntdef.h | 2 +- include/windef.h | 4 ++-- include/winnt.h | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-)
This might be a dumb question, but why not define LONG to be int32_t on all platforms?
-Alex
April 28, 2020 2:15 PM, "Alex Henrie" alexhenrie24@gmail.com wrote:
This might be a dumb question, but why not define LONG to be int32_t on all platforms?
Uhh, because 'int32_t' isn't necessarily 'long' on Windows?
-Alex
Chip
On Tue, Apr 28, 2020 at 1:16 PM Chip Davis cdavis@codeweavers.com wrote:
April 28, 2020 2:15 PM, "Alex Henrie" alexhenrie24@gmail.com wrote:
This might be a dumb question, but why not define LONG to be int32_t on all platforms?
Uhh, because 'int32_t' isn't necessarily 'long' on Windows?
According to MSDN, LONG is a 32-bit signed integer.[1] Is the problem that if a program uses LONG in a function declaration and then long in the function definition, it wouldn't compile if LONG is defined to be int, even on a 32-bit MSVC-like platform where both int and long represent 32-bit signed integers?
-Alex
[1] https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
April 28, 2020 2:39 PM, "Alex Henrie" alexhenrie24@gmail.com wrote:
On Tue, Apr 28, 2020 at 1:16 PM Chip Davis cdavis@codeweavers.com wrote:
April 28, 2020 2:15 PM, "Alex Henrie" alexhenrie24@gmail.com wrote:
This might be a dumb question, but why not define LONG to be int32_t on all platforms?
Uhh, because 'int32_t' isn't necessarily 'long' on Windows?
According to MSDN, LONG is a 32-bit signed integer.[1] Is the problem that if a program uses LONG in a function declaration and then long in the function definition, it wouldn't compile if LONG is defined to be int, even on a 32-bit MSVC-like platform where both int and long represent 32-bit signed integers?
Pretty much. Well that, and you'll see warnings if you use an expression of type 'LONG' with a printf(3) format spec like "%ld".
-Alex
[1] https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
Chip
On Tue, Apr 28, 2020 at 2:50 PM Chip Davis cdavis@codeweavers.com wrote:
April 28, 2020 2:39 PM, "Alex Henrie" alexhenrie24@gmail.com wrote:
On Tue, Apr 28, 2020 at 1:16 PM Chip Davis cdavis@codeweavers.com wrote:
April 28, 2020 2:15 PM, "Alex Henrie" alexhenrie24@gmail.com wrote:
This might be a dumb question, but why not define LONG to be int32_t on all platforms?
Uhh, because 'int32_t' isn't necessarily 'long' on Windows?
According to MSDN, LONG is a 32-bit signed integer.[1] Is the problem that if a program uses LONG in a function declaration and then long in the function definition, it wouldn't compile if LONG is defined to be int, even on a 32-bit MSVC-like platform where both int and long represent 32-bit signed integers?
Pretty much. Well that, and you'll see warnings if you use an expression of type 'LONG' with a printf(3) format spec like "%ld".
That makes sense. Thanks for the explanation!
-Alex
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
Right now we use _MSC_VER to choose between long and int type. We could, however, make any other choice. With patch 1, it's possible to use int with MSVC (or at least clang MSVC target). It's also possible for any other compilers except __LP64__ to use long.
This raises some questions and I wouldn't mind changing the patch. For example, I could change headers to always use int. The problem with that is that it makes us incompatible with the rest of Windows world.
In the past, the choice of int for LONG was motivated by port to Win64, where we can't use long on UNIX side and it's nice to have the same time on all targets.
This patch is a compromise: it always uses int for Wine itself, so as far as building Wine is considered, it's consistent among compilers. Outside Wine, it uses long on Windows targets, where the code is most likely to depend on underlying type. And it keeps using int for non-Windows targets, so nothing changes for non-PE winelib.
If there is a need for int LONG on Windows targets, we could introduce a macro to change that choice. I could also imagine revisiting the choice for PE parts of Wine itself, but it would be a lot of work.
All of these options are of course possible, but it doesn't seem to me that any of them has a clear advantage over what we are doing now. Are there real problems with the current approach that we need to address?
On 29.04.2020 22:44, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
Right now we use _MSC_VER to choose between long and int type. We could, however, make any other choice. With patch 1, it's possible to use int with MSVC (or at least clang MSVC target). It's also possible for any other compilers except __LP64__ to use long.
This raises some questions and I wouldn't mind changing the patch. For example, I could change headers to always use int. The problem with that is that it makes us incompatible with the rest of Windows world.
In the past, the choice of int for LONG was motivated by port to Win64, where we can't use long on UNIX side and it's nice to have the same time on all targets.
This patch is a compromise: it always uses int for Wine itself, so as far as building Wine is considered, it's consistent among compilers. Outside Wine, it uses long on Windows targets, where the code is most likely to depend on underlying type. And it keeps using int for non-Windows targets, so nothing changes for non-PE winelib.
If there is a need for int LONG on Windows targets, we could introduce a macro to change that choice. I could also imagine revisiting the choice for PE parts of Wine itself, but it would be a lot of work.
All of these options are of course possible, but it doesn't seem to me that any of them has a clear advantage over what we are doing now. Are there real problems with the current approach that we need to address?
The main problem that I tried to address is that with current approach, building Wine itself in MSVC mode causes a lot of format warnings and some incompatible pointer type warnings. That's because MSVC is #ifdefed to use long. To fix that problem, we probably could just remove MSVC ifdef and always use int, but entirely removing support for using long doesn't seem right to me. Maybe change #ifdef _MSV_VER with some WINE_* opt-in macro?
Thanks,
Jacek
Jacek Caban jacek@codeweavers.com writes:
On 29.04.2020 22:44, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Signed-off-by: Jacek Caban jacek@codeweavers.com
Right now we use _MSC_VER to choose between long and int type. We could, however, make any other choice. With patch 1, it's possible to use int with MSVC (or at least clang MSVC target). It's also possible for any other compilers except __LP64__ to use long.
This raises some questions and I wouldn't mind changing the patch. For example, I could change headers to always use int. The problem with that is that it makes us incompatible with the rest of Windows world.
In the past, the choice of int for LONG was motivated by port to Win64, where we can't use long on UNIX side and it's nice to have the same time on all targets.
This patch is a compromise: it always uses int for Wine itself, so as far as building Wine is considered, it's consistent among compilers. Outside Wine, it uses long on Windows targets, where the code is most likely to depend on underlying type. And it keeps using int for non-Windows targets, so nothing changes for non-PE winelib.
If there is a need for int LONG on Windows targets, we could introduce a macro to change that choice. I could also imagine revisiting the choice for PE parts of Wine itself, but it would be a lot of work.
All of these options are of course possible, but it doesn't seem to me that any of them has a clear advantage over what we are doing now. Are there real problems with the current approach that we need to address?
The main problem that I tried to address is that with current approach, building Wine itself in MSVC mode causes a lot of format warnings and some incompatible pointer type warnings. That's because MSVC is #ifdefed to use long. To fix that problem, we probably could just remove MSVC ifdef and always use int, but entirely removing support for using long doesn't seem right to me. Maybe change #ifdef _MSV_VER with some WINE_* opt-in macro?
Yes, we could provide a macro for tweaking this.
-
Alex Henrie -
Alexandre Julliard -
Chip Davis -
Jacek Caban