Hello, On just about every file that is built we are getting this warrning. This is the most minor problem we have with the alpha build but I couldnt figure it out.
../../include/wine/debug.h: In function `wine_dbgstr_guid': ../../include/wine/debug.h:152: warning: cast from pointer to integer of different size ../../include/wine/debug.h:152: warning: cast from pointer to integer of different size
This system is a Alpha AXP 21164.
Thanks Steven
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Le sam 19/07/2003 à 02:42, Steven Edwards a écrit :
Hello, On just about every file that is built we are getting this warrning. This is the most minor problem we have with the alpha build but I couldnt figure it out.
../../include/wine/debug.h: In function `wine_dbgstr_guid': ../../include/wine/debug.h:152: warning: cast from pointer to integer of different size ../../include/wine/debug.h:152: warning: cast from pointer to integer of different size
That's an easy one. One an Alpha, sizeof(int) != sizeof(foo *). I think sizeof(int) == 8, while sizeof(foo *) == 4.
gcc is kind enough to warn you about this potentially nasty situation, although in these particular cases I don't see how putting the pointer in something larger will create a problem.
Still, fixing the warning would be a good idea as there's probably a whole lot of lines passing by at compilation.
Vincent
On Sat, 19 Jul 2003, Vincent Béron wrote:
: That's an easy one. One an Alpha, sizeof(int) != sizeof(foo *). I think : sizeof(int) == 8, while sizeof(foo *) == 4.
Other way round. sizeof(int) == 4; sizeof(void *) == 8.
: gcc is kind enough to warn you about this potentially nasty situation, : although in these particular cases I don't see how putting the pointer : in something larger will create a problem.
Use intptr_t. If that's not available (via autoconf test), typedef intptr_t to be "unsigned long" locally, as "long" is the size of a pointer on all typical ILP32 and LP64 hosts.
Todd Vierling wrote:
On Sat, 19 Jul 2003, Vincent Béron wrote:
: That's an easy one. One an Alpha, sizeof(int) != sizeof(foo *). I think : sizeof(int) == 8, while sizeof(foo *) == 4.
Other way round. sizeof(int) == 4; sizeof(void *) == 8.
: gcc is kind enough to warn you about this potentially nasty situation, : although in these particular cases I don't see how putting the pointer : in something larger will create a problem.
Use intptr_t. If that's not available (via autoconf test), typedef intptr_t to be "unsigned long" locally, as "long" is the size of a pointer on all typical ILP32 and LP64 hosts.
The reason something is a warning and not an error is that it MAY have a legitimate use. As such, there should always be a way to change the code so that it will keep the same meaning, but will avoid the warning in the future. In this particular case, for example, what does applying the following change do? - if (!((int)id >> 16)) return wine_dbg_sprintf( "<guid-0x%04x>", (int)id & 0xffff ); + if (!((int)id >> 16)) return wine_dbg_sprintf( "<guid-0x%04x>", (UINT16)id );
I'm a bit confused. gcc seems to be warning us about an explicit cast? I always thought that, in C, explicit casts are THE way of avoiding compile time warnings. Why should one change the semantic meaning of the code just so that gcc is pacified?
Shachar
On Sat, 19 Jul 2003, Shachar Shemesh wrote:
: >Use intptr_t. If that's not available (via autoconf test), typedef intptr_t : >to be "unsigned long" locally, as "long" is the size of a pointer on all : >typical ILP32 and LP64 hosts.
: The reason something is a warning and not an error is that it MAY have a : legitimate use. As such, there should always be a way to change the code : so that it will keep the same meaning, but will avoid the warning in the : future.
Yes. "Use intptr_t", just like I've already said.
: In this particular case, for example, what does applying the : following change do? : - if (!((int)id >> 16)) return wine_dbg_sprintf( "<guid-0x%04x>", : (int)id & 0xffff ); : + if (!((int)id >> 16)) return wine_dbg_sprintf( "<guid-0x%04x>", : (UINT16)id ); : : I'm a bit confused. gcc seems to be warning us about an explicit cast?
Yes, because explicitly casting a pointer to an integer of a smaller size is unportable (it's even warned against in the current C standards), and can cause crashes. The most common usage is void* -> int -> void*, which used to be in huge swaths of C code before it was pruned out for LP64 usage.
To do this correctly per the C standard, cast to an integer of at least the pointer's size (intptr_t), and then cast it further down:
For the first case,
((intptr_t)id >> 16)
For the second one,
(UINT16)(intptr_t)id
Le sam 19/07/2003 à 13:01, Shachar Shemesh a écrit :
Todd Vierling wrote:
On Sat, 19 Jul 2003, Vincent Béron wrote:
: That's an easy one. One an Alpha, sizeof(int) != sizeof(foo *). I think : sizeof(int) == 8, while sizeof(foo *) == 4.
Other way round. sizeof(int) == 4; sizeof(void *) == 8.
: gcc is kind enough to warn you about this potentially nasty situation, : although in these particular cases I don't see how putting the pointer : in something larger will create a problem.
Use intptr_t. If that's not available (via autoconf test), typedef intptr_t to be "unsigned long" locally, as "long" is the size of a pointer on all typical ILP32 and LP64 hosts.
The reason something is a warning and not an error is that it MAY have a legitimate use. As such, there should always be a way to change the code so that it will keep the same meaning, but will avoid the warning in the future. In this particular case, for example, what does applying the following change do?
- if (!((int)id >> 16)) return wine_dbg_sprintf( "<guid-0x%04x>",
(int)id & 0xffff );
- if (!((int)id >> 16)) return wine_dbg_sprintf( "<guid-0x%04x>",
(UINT16)id );
You'll have to do it also at the beginning of the line.
I'm a bit confused. gcc seems to be warning us about an explicit cast? I always thought that, in C, explicit casts are THE way of avoiding compile time warnings. Why should one change the semantic meaning of the code just so that gcc is pacified?
I think for pointers (especially when you change the size of the result) gcc is more picky. Compile the attached program to verify.
And I don't remember Steven saying that he actually used gcc or even Linux on the Alpha, it could be the DEC cc under Tru-64...
Vincent
I think for pointers (especially when you change the size of the result) gcc is more picky. Compile the attached program to verify.
And I don't remember Steven saying that he actually used gcc or even Linux on the Alpha, it could be the DEC cc under Tru-64...
Its gcc on RH 7.1 for Alpha. On a Dec PWS 500 workstation. I dont know anything about Alpha asm so I cannot implement the interlocked* functions or the import and spec support in winebuild so I have just stubbed it for now. The other issues I am having is with compiling resources. WRC doesnot work proplerly on Alpha and I dont know why.
I will try your suggestions tonight.
Thanks Steven
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
"Todd Vierling" tv@pobox.com wrote:
: That's an easy one. One an Alpha, sizeof(int) != sizeof(foo *). I think : sizeof(int) == 8, while sizeof(foo *) == 4.
Other way round. sizeof(int) == 4; sizeof(void *) == 8.
In that case Wine needs to be compiled with _WIN64 macro defined. In that case WPARAM and LPARAM will have correct size as well. But be warned that compiling for Win64 is a completely unexplored terrain.
: gcc is kind enough to warn you about this potentially nasty situation, : although in these particular cases I don't see how putting the pointer : in something larger will create a problem.
Use intptr_t. If that's not available (via autoconf test), typedef intptr_t to be "unsigned long" locally, as "long" is the size of a pointer on all typical ILP32 and LP64 hosts.
In Wine we have to use UINT_PTR, ULONG_PTR, DWORD_PTR for casting pointer to an integer type. These macros have correct behaviour on Win32 and Win64.
--- Dmitry Timoshkov dmitry@baikal.ru wrote:
Other way round. sizeof(int) == 4; sizeof(void *) == 8.
In that case Wine needs to be compiled with _WIN64 macro defined. In that case WPARAM and LPARAM will have correct size as well. But be warned that compiling for Win64 is a completely unexplored terrain.
: gcc is kind enough to warn you about this potentially nasty situation, : although in these particular cases I don't see how putting the pointer : in something larger will create a problem.
Use intptr_t. If that's not available (via autoconf test), typedef intptr_t to be "unsigned long" locally, as "long" is the size of a pointer on all typical ILP32 and LP64 hosts.
In Wine we have to use UINT_PTR, ULONG_PTR, DWORD_PTR for casting pointer to an integer type. These macros have correct behaviour on Win32 and Win64.
So if I define the _WIN64 macro for AXP all of the *_PTR should be ok right? I will submit a patch for this in short order.
I have this Alpha that HP loaned us for ReactOS but I have never been able to build a current gcc/binutils that build for a alpha-pe target. I figure while I still have it then I will work on getting WINE working. Anyone know AXP assembly interested in helping with the port? I will put it on the net with SSH if anyone wants to play with it.
Thanks Steven
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
On Sat, 19 Jul 2003, Steven Edwards wrote:
: > In Wine we have to use UINT_PTR, ULONG_PTR, DWORD_PTR for casting pointer : > to an integer type. These macros have correct behaviour on Win32 and Win64. : : So if I define the _WIN64 macro for AXP all of the *_PTR should be ok right? I will submit a patch : for this in short order. : : I have this Alpha that HP loaned us for ReactOS but I have never been able to build a current : gcc/binutils that build for a alpha-pe target. I figure while I still have it then I will work on : getting WINE working. Anyone know AXP assembly interested in helping with the port?
You should be aware that NT on Alpha was *NOT* a LP64 operating system (whereas Windows on IA64 is indeed LP64), and I'm presuming that the "alpha-pe" is targeting the classical NT/Alpha configuration. The ARC BIOS that was used to load NT created a memory map that simulated a 32-bit memory space, thus essentially making an Alpha behave much like an x86 -- well, sort of.
A Wine compiled as Win64 will likely not be able to run Alpha NT binaries. However, it might work reasonably well to compile apps with Winelib.
--- Todd Vierling tv@pobox.com wrote:
You should be aware that NT on Alpha was *NOT* a LP64 operating system (whereas Windows on IA64 is indeed LP64), and I'm presuming that the "alpha-pe" is targeting the classical NT/Alpha configuration. The ARC BIOS that was used to load NT created a memory map that simulated a 32-bit memory space, thus essentially making an Alpha behave much like an x86 -- well, sort of.
A Wine compiled as Win64 will likely not be able to run Alpha NT binaries. However, it might work reasonably well to compile apps with Winelib.
I dont really care so much about being compatible with Alpha NT stuff. I know Marcus broke the NT PPC compatiblity stuff for his Winelib port so I think its a non-issue for anyone here.
I just wonder how M$ did this for Win2K RC1. I have a copy of this and it supported older Alpha NT apps even though it was supposed to be LP64. I dont know that much about the lower level stuff so maybe they figured out a way to do both. They did have Fx32 built in also for X86 apps so maybe it was extended to support LP32 alpha apps in 64 bit mode.
Thanks Steven
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
On Sat, Jul 19, 2003 at 11:37:12PM -0700, Steven Edwards wrote:
--- Todd Vierling tv@pobox.com wrote:
You should be aware that NT on Alpha was *NOT* a LP64 operating system (whereas Windows on IA64 is indeed LP64), and I'm presuming that the "alpha-pe" is targeting the classical NT/Alpha configuration. The ARC BIOS that was used to load NT created a memory map that simulated a 32-bit memory space, thus essentially making an Alpha behave much like an x86 -- well, sort of.
A Wine compiled as Win64 will likely not be able to run Alpha NT binaries. However, it might work reasonably well to compile apps with Winelib.
I dont really care so much about being compatible with Alpha NT stuff. I know Marcus broke the NT PPC compatiblity stuff for his Winelib port so I think its a non-issue for anyone here.
Side note: The ABI is broken just for 1 register (TEB), since it is used by the Linux/PPC ABI.
Ciao, Marcus
-
Dmitry Timoshkov -
Marcus Meissner -
Shachar Shemesh -
Steven Edwards -
Todd Vierling -
Vincent Béron