C2220 & 32bit app on 64 bit driver
in [Device Drivers]
|
From: Prafulla on 9 Mar 2010 07:44 Hi, During the driver build, I am getting the C2220 warning as error on WDK-6000 build environment, how to disable this warning. I am supporting 32 bit app on 64 bit drivers, so I am passing IOCTL variables in form of ULONG32 & ULONG_PTR, so that, width of these variable will be always same in 32/64 bit process. I am also using WdfRequestIoIs32bitProcess where ever required, but avoided for most of IOCTl's by abpve method. IOCTL struct ==> ULONG_PTR var Driver output ==> void * pointer var = (ULONG_PTR)pointer Above line causing the C2220 warning. In the sources file, there is no /wx flag added, I guess it is taken by default in WDK-6000. Is there any way to disable this?, I tried Pragma, but not working. Thanks, Kota
From: Don Burn on 9 Mar 2010 07:55 First dig out the other warning, since C2220 does not appear without another warning. Second, you state that you pass things in the form of ULONG_PTR which for a 32-bit process is 32 bits, but for a 64 bit driver is 64 bits. So I suspect that is your problem. Without real code and the warning that is triggering the C2220 that is all anyone can guess. Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr > -----Original Message----- > From: Prafulla [mailto:Prafulla(a)newsgroup.nospam] > Posted At: Tuesday, March 09, 2010 7:44 AM > Posted To: microsoft.public.development.device.drivers > Conversation: C2220 & 32bit app on 64 bit driver > Subject: C2220 & 32bit app on 64 bit driver > > Hi, > > During the driver build, I am getting the C2220 warning as error on > WDK-6000 build environment, how to disable this warning. > > I am supporting 32 bit app on 64 bit drivers, so I am passing IOCTL > variables in form of ULONG32 & ULONG_PTR, so that, width of these > variable will be always same in 32/64 bit process. > I am also using WdfRequestIoIs32bitProcess where ever required, but > avoided for most of IOCTl's by abpve method. > > IOCTL struct ==> ULONG_PTR var > Driver output ==> void * pointer > > var = (ULONG_PTR)pointer > Above line causing the C2220 warning. > > In the sources file, there is no /wx flag added, I guess it is taken by > default in WDK-6000. > > Is there any way to disable this?, I tried Pragma, but not working. > > Thanks, > Kota > > > __________ Information from ESET Smart Security, version of virus > signature database 4928 (20100309) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com >
From: Maxim S. Shatskih on 9 Mar 2010 09:15 > I am supporting 32 bit app on 64 bit drivers, so I am passing IOCTL > variables in form of ULONG32 & ULONG_PTR, so that, width of these variable > will be always same in 32/64 bit process. Do you have pointers or handles in the IOCTL structures? If not - then forget all 32/64 issues and use usual ULONG-style types. If not so - then make and #ifdef _WIN64 in the header file, and, in this #ifdef, declare the same structure, but with something like: VOID *POINTER_32 hEvent; for all handles and pointers in it. The new structure should be declared with the name postfixed with "32", or like this. The apps are the built without paying attention to this, they just use the usual structure type name. In the driver, use WdfRequestIoIs32bitProcess in this IOCTL path, and interpret the IOCTL's buffer either as usual structure type or as "32" structure type. Just sign-extend the pointer and handle values (like (PVOID)(ULONG_PTR)(ULONG)) from the "32" structure in this case. Surely this is only for 64bit driver build, 32bit driver build just blindly uses the usual structure type. I think all of this is well-covered in MSDN. > IOCTL struct ==> ULONG_PTR var > Driver output ==> void * pointer I cannot understand what these things mean. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Maxim S. Shatskih on 9 Mar 2010 09:19 > another warning. Second, you state that you pass things in the form of > ULONG_PTR which for a 32-bit process is 32 bits, but for a 64 bit driver > is 64 bits. So I suspect that is your problem. Correct. I would never use ULONG_PTR (or size_t which is another name of it) in IOCTL buffer. If the numeric value is needed - ULONG or ULONGLONG are much better, and pointers should be used as pointers (as PVOID in the worst case). But, in general C/C++ code, I would use size_t whenever possible for all sizes and pointer offsets and differences. If necessary, size_t is downcasted to ULONG exactly near the DeviceIoControl call, and near most Win32 or NT kernel calls (historically they do not use size_t). -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Alexander Grigoriev on 9 Mar 2010 09:59 size_t is 64 bit in x64 build. "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message news:e3O4CO5vKHA.5008(a)TK2MSFTNGP05.phx.gbl... > another warning. Second, you state that you pass things in the form of > ULONG_PTR which for a 32-bit process is 32 bits, but for a 64 bit driver > is 64 bits. So I suspect that is your problem. Correct. I would never use ULONG_PTR (or size_t which is another name of it) in IOCTL buffer. If the numeric value is needed - ULONG or ULONGLONG are much better, and pointers should be used as pointers (as PVOID in the worst case). But, in general C/C++ code, I would use size_t whenever possible for all sizes and pointer offsets and differences. If necessary, size_t is downcasted to ULONG exactly near the DeviceIoControl call, and near most Win32 or NT kernel calls (historically they do not use size_t). -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
|
Next
|
Last
Pages: 1 2 Prev: DTM: USB-IF test certification ID check Next: Hub and Tracker the problem- use a USBtracer |