Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
“What do you think is the worst that could happen by issuing a 0 + on an integer value that is meant to be used as a valid pointer in the first place?” Remember: (((int32_t *)0) + 5) == 20. From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Redirect Slash NIL Sent: Saturday, October 17, 2009 6:14 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64 2009/10/17 David Brownell davi...@pacbell.netmailto:davi...@pacbell.net What's with the strange (HANDLE)(0 + _get_osfhandle())? The 0 + is mutant... Yeah. The problem here is that HANDLE is typedef'd as void* (in winnt.h), whereas _get_osfhandle() returns a long (http://msdn.microsoft.com/en-us/library/ks2530z6.aspx), and gcc insists on returning a warning when casting a 32 bit long into a 64 bit pointer (cast to pointer from integer of different size). The most elegant way I found to avoid that warning is to do an arithmetic operation first. Of course one has to wonder why a function that is meant to return a handle does not actually return a type HANDLE... The only other way I see to do it is to add idefs for MINGW64 so that we cast _get_osfhandle() to a long long first. What do you think is the worst that could happen by issuing a 0 + on an integer value that is meant to be used as a valid pointer in the first place? _get_osfhandle is meant to provide a pointer (handle) that is valid for the OS it's actually being executed in. It's just that for whatever reason, the makers of that function decided to return anything but a handle but I still think what we're doing here should be pretty safe. Regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
A very valid point indeed. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
What's with the strange (HANDLE)(0 + _get_osfhandle())? The 0 + is mutant... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
2009/10/17 David Brownell davi...@pacbell.net What's with the strange (HANDLE)(0 + _get_osfhandle())? The 0 + is mutant... Yeah. The problem here is that HANDLE is typedef'd as void* (in winnt.h), whereas _get_osfhandle() returns a long ( http://msdn.microsoft.com/en-us/library/ks2530z6.aspx), and gcc insists on returning a warning when casting a 32 bit long into a 64 bit pointer (cast to pointer from integer of different size). The most elegant way I found to avoid that warning is to do an arithmetic operation first. Of course one has to wonder why a function that is meant to return a handle does not actually return a type HANDLE... The only other way I see to do it is to add idefs for MINGW64 so that we cast _get_osfhandle() to a long long first. What do you think is the worst that could happen by issuing a 0 + on an integer value that is meant to be used as a valid pointer in the first place? _get_osfhandle is meant to provide a pointer (handle) that is valid for the OS it's actually being executed in. It's just that for whatever reason, the makers of that function decided to return anything but a handle but I still think what we're doing here should be pretty safe. Regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
Hello Redirect, Sunday, October 18, 2009, 1:14:20 AM, you wrote: RSN Yeah. The problem here is that HANDLE is typedef'd as void* (in RSN winnt.h), whereas _get_osfhandle() returns a long RSN (http://msdn.microsoft.com/en-us/library/ks2530z6.aspx), and gcc RSN insists on returning a warning when casting a 32 bit long into a RSN 64 bit pointer (cast to pointer from integer of different size). RSN The most elegant way I found to avoid that warning is to do an arithmetic operation first. RSN Of course one has to wonder why a function that is meant to RSN return a handle does not actually return a type HANDLE... RSN The only other way I see to do it is to add idefs for MINGW64 so RSN that we cast _get_osfhandle() to a long long first. Actually, in VC9 it returns intptr_t (MSDN is wrong here): _CRTIMP intptr_t __cdecl _get_osfhandle(_In_ int _FileHandle); (from io.h) So it might be worth it to get mingw people to fix their headers... -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
On Saturday 17 October 2009, Redirect Slash NIL wrote: The 0 + is mutant... Yeah. The problem here is that HANDLE is typedef'd as void* (in winnt.h), whereas _get_osfhandle() returns a long ( http://msdn.microsoft.com/en-us/library/ks2530z6.aspx), and gcc insists on returning a warning when casting a 32 bit long into a 64 bit pointer (cast to pointer from integer of different size). The most elegant way I found to avoid that warning is to do an arithmetic operation first. Linux solves that by casting first to intptr_t: long l = ...; void *p; p = (void *)(intptr_t) l; That would work better with Igor's suggestion too. Could you send me a patch you've verified works, using that approach? I'm sort of opposed to mutant code. ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
2009/10/18 Igor Skochinsky skochin...@mail.ru Actually, in VC9 it returns intptr_t (MSDN is wrong here): _CRTIMP intptr_t __cdecl _get_osfhandle(_In_ int _FileHandle); (from io.h) So it might be worth it to get mingw people to fix their headers... Actually, the io.h from MinGW-W64 does have the same declaration as VC9. Looks like most people, including the original coder and myself, thought MSDN was providing accurate data. I now see that now there's a comment on that page that warns 64 bit programmers as well... From my testing, it looks like using an intptr_t rather than a long works on both cygwin and mingw-w64, despite the fact that cygwin still uses extern long get_osfhandle(int); in their io.h I guess this won't matter to them till they go 64 bit, which doesn't look likely for now. 2009/10/18 David Brownell davi...@pacbell.net Linux solves that by casting first to intptr_t: Could you send me a patch you've verified works, using that approach? No sooner said than done. Tested on both mingw-w64 and cygwin-w32 - no warnings. I preferred doing away with the long altogether, rather than use the double cast. patch_long_to_handler_mingw_w64_v2.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
Forgot a cast on _get_osfhandle(i); Here's a safer (and hopefully final) version. patch_long_to_handler_mingw_w64_v3.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
This fix addresses the cast warnings issued on MinGW-W64 when casting a long to HANDLER in replacement.c Also removes the need for a temporary variable. patch_long_to_handler_mingw_w64.diff Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
