I have been coding my driver using KMDF and my source file ends in .cpp. I am not using classes, etc., but I believe this is the standard way of
developing, right? But when I try to use the Static Driver Verifier I get the error: “Cannot process this driver. It has C++ code.” Should I change
the name of my file to .c?
Yes, many people do just what you are doing, using .cpp for c files.
If you want to use SDV, then, yes, you will have to change the extension,
but you can still compile them as C++ by adding ‘/TP’ to the cl command line
(I think that adding it to the ‘USER_C_FLAGS’ macro will achieve this in
‘BUILD.’)
Personally, if you don’t already, I’d REALLY recommend that you use PreFAST
at least BEFORE you use SDV. If you want to use both, knock yourself out,
but, personally, I’ve yet to see the upside to using SDV at all.
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Wade
Sent: Thursday, January 13, 2011 5:45 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Static Driver Verifier and C++?
I have been coding my driver using KMDF and my source file ends in .cpp. I
am not using classes, etc., but I believe this is the standard way of
developing, right? But when I try to use the Static Driver Verifier I get
the error: “Cannot process this driver. It has C++ code.” Should I change
the name of my file to .c?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
It is *a* standard way of developing. It’s what we do as a matter of course here at OSR.
You should IF you want to use Static Driver Verifier.
You’ll probably also have to change a few OTHER small, seemingly innocuous, things in your code as well.
Here at OSR, for device driver development projects, once we think we’ve got the driver in pretty decent shape, we’ll go through the (VERY annoying) exercise of changing the file types to .C and making it compile with the C compiler. And then run it through SDV, in the hope that it will turn up something useful.
When we’re done playing with SDV, we rename the files to CPP, and we carry on with our development.
Peter
OSR
> …we’ll go through the (VERY annoying) exercise of changing the file types to .C and making
it compile with the C compiler.
What about automating the whole process of changing file extension from .c. to .cpp and back by writing a small utility for this purpose so that it can get done programmatically, rather than by hand??? I know it is a bit cumbersome under Windows, compared to UNIX, but still the whole thing seems to be worth an effort, don’t you think…
Anton Bassov
Strange that you should ask about that. I very much would like to use PREFast but I must have done something wrong. Installed complete WinDDK
7600.16385.1. Open a build environment for Win7x64. OACR starts up (at some point, can’t remember exactly when). When I build my driver I get:
build -ce
BUILD: Compile and Link for AMD64
BUILD: Loading c:\winddk\7600.16385.1\build.dat…
BUILD: Computing Include file dependencies:
BUILD: Start time: Thu Jan 13 16:19:25 2011
BUILD: Examining c:\tapestry\test\driver\win7\tappci\driver directory for files
to compile.
BUILD: Saving c:\winddk\7600.16385.1\build.dat…
BUILD: Compiling and Linking c:\tapestry\test\driver\win7\tappci\driver director
y
Configuring OACR for ‘root:amd64chk’ -
Compiling - tappci.cpp
Linking Executable - objchk_win7_amd64\amd64\tappci.sys
BUILD: Finish time: Thu Jan 13 16:19:45 2011
BUILD: Done
OACR starts crunching away, then I get the error:
PREfast - Error processing ‘tappci.cpp’ : error C2371 : ‘size_t’ : redefinition; different basic types (try ‘oacr log root:amd64chk’ for details)
Source Path c:\winddk\7600.1385.1\inc\crt<br>Source Location: crtdefs.h(457)
Looking at the log, it points to this same error. crtdefs.h at line 457
#ifdef _WIN64
typedef unsigned int64 size_t;
typedef int64 intptr_t;
typedef unsigned int64 uintptr_t;
typedef int64 ptrdiff_t;
#else
typedef _W64 unsigned int size_t;
typedef _W64 int intptr_t;
typedef _W64 unsigned int uintptr_t;
typedef _W64 int ptrdiff_t;
#endif
Somehow it looks like the _WIN64 def is getting messed with. But how? And how for only the PREfast?
On Thu, 13 Jan 2011 17:50:48 -0500, “Martin O’Brien” wrote:
>Yes, many people do just what you are doing, using .cpp for c files.
>
>If you want to use SDV, then, yes, you will have to change the extension,
>but you can still compile them as C++ by adding ‘/TP’ to the cl command line
>(I think that adding it to the ‘USER_C_FLAGS’ macro will achieve this in
>‘BUILD.’)
>
>Personally, if you don’t already, I’d REALLY recommend that you use PreFAST
>at least BEFORE you use SDV. If you want to use both, knock yourself out,
>but, personally, I’ve yet to see the upside to using SDV at all.
>
>
>Good luck,
>
>mm
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Wade
>Sent: Thursday, January 13, 2011 5:45 PM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] Static Driver Verifier and C++?
>
>I have been coding my driver using KMDF and my source file ends in .cpp. I
>am not using classes, etc., but I believe this is the standard way of
>developing, right? But when I try to use the Static Driver Verifier I get
>the error: “Cannot process this driver. It has C++ code.” Should I change
>the name of my file to .c?
>
>—
>NTDEV is sponsored by OSR
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
And I have tried rebooting, “clean” etc. Everything that I could think of.
Oh and this is odd, may be a clue or it may be nothing. If I look at the “About OACR” it says:
Configuration: C:\WinDDK\7600.16385.1\bin\x86\oacr\oacr.ini
Customizations:
I would have thought it would reference the x64 (amd64) oacr.ini file, not the x86. I checked, the amd64 oacr.ini is there…
There is the USECXX_FLAG=1 option in your sources file as a possibility (though I don’t personally care for using that liberally myself).
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, January 13, 2011 2:53 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Static Driver Verifier and C++?
It is *a* standard way of developing. It’s what we do as a matter of course here at OSR.
You should IF you want to use Static Driver Verifier.
You’ll probably also have to change a few OTHER small, seemingly innocuous, things in your code as well.
Here at OSR, for device driver development projects, once we think we’ve got the driver in pretty decent shape, we’ll go through the (VERY annoying) exercise of changing the file types to .C and making it compile with the C compiler. And then run it through SDV, in the hope that it will turn up something useful.
When we’re done playing with SDV, we rename the files to CPP, and we carry on with our development.
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Good idea, Anton! That would be an excellent contribution to the community. You write the utility, and we’ll happily post it on OSR Online for download.
Peter
OSR
Peter,
Good idea, Anton! That would be an excellent contribution to the community. You write the utility,
and we’ll happily post it on OSR Online for download.
In fact, I haven’t got Windows anywhere in sight, but, as long as this utility runs on the command line, this kind of thing can be, apparently, done under Linux, right - after all, it does not seem to involve anything system-specific so that it,apparently, can be done in plain ANSI C (unless I forgot too much about UM Windows programming, of course). Please remind me the sequence of steps that you take manually (IIRC, it must involve editing SOURCES file and changing file extensions, right) and send me a sample SOURCES file so that I can recall its structure. At this point I will be able to write a simple Linux app and send you its code so that you will be able to build a Windows console app that reads SOURCES, updates it and renames files of interest in the target directory…
Anton Bassov
So sorry to hear that. You’ve got yourself stuck in the Land of The Penguin, I presume?
Heck… write it in Perl !
That’s a nice offer but… well… renaming the files and changing SOURCES isn’t what takes the time. That’s like a 2 minute thing.
That takes the TIME is going through the app and removing all the little differences between C and C++ – I was surprised at how many tiny differences there were. Some were well-known to me (like structure declarations… I still do it the “traditional” way in any case), but I was surprised about some small incompatibility about braces usage in a switch statement or something (in C++ they were optional and in C they weren’t?? Do I remember that right??)
So, unless you want to tackle language parsing, which is what I was really suggesting, I don’t think such a utility will be all that helpful.
I *do* appreciate your willingness to contribute, however… even if you ARE cursed to be in Penguin Land.
Peter
OSR
I guess I don’t understand the “rename” in this approach. If the files
are .CPP add /TC to the compiler arguments in the SOURCES file and the
compiler will treat them as .C , if the files are .C add /TP and the
compiler will treat them as .CPP
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@osr.com” wrote in message news:xxxxx@ntdev:
>
>
> It is a standard way of developing. It’s what we do as a matter of course here at OSR.
>
>
>
> You should IF you want to use Static Driver Verifier.
>
> You’ll probably also have to change a few OTHER small, seemingly innocuous, things in your code as well.
>
> Here at OSR, for device driver development projects, once we think we’ve got the driver in pretty decent shape, we’ll go through the (VERY annoying) exercise of changing the file types to .C and making it compile with the C compiler. And then run it through SDV, in the hope that it will turn up something useful.
>
> When we’re done playing with SDV, we rename the files to CPP, and we carry on with our development.
>
> Peter
> OSR
Don Burn wrote:
I guess I don’t understand the “rename” in this approach. If the files
are .CPP add /TC to the compiler arguments in the SOURCES file and the
compiler will treat them as .C , if the files are .C add /TP and the
compiler will treat them as .CPP
The issue is SDV, which will not touch a driver with .CPP files. I
would not be comfortable naming my files with a .C extension if they
really contained C++ code, so if one wants to take advantage of SDV in
that case, one must rename.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> That takes the TIME is going through the app and removing all the little differences between C and C++ –
Hold on - I though that this is the point of the whole exercise with renaming files, i.e. you want to ensure that you produce a source file that can get compiled with both .c and .cpp extensions successfully, so that, on one hand, you avoid “creeping C++ danger” that Don had mentioned in one of the discussions, and, on another hand, enforce strong type checking that C++ implies. Therefore, you should, apparently, do this test quite frequently, i.e. every time you apply more or less significant modification to the source - otherwise the whole thing may get out of control pretty shortly. This is why I mentioned automation - I thought that you are tired of renaming files back and forth by hand every other 5 minutes …
Anton Bassov
But SDV is also not comfortable with C++ syntax, so you .CPP files have
to be C code only if they are going to go through SDV. I know that the
OSR code I have received over the years had files named .CPP but they
could be renamed .C and work fine.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Tim Roberts” wrote in message news:xxxxx@ntdev:
> Don Burn wrote:
> > I guess I don’t understand the “rename” in this approach. If the files
> > are .CPP add /TC to the compiler arguments in the SOURCES file and the
> > compiler will treat them as .C , if the files are .C add /TP and the
> > compiler will treat them as .CPP
>
> The issue is SDV, which will not touch a driver with .CPP files. I
> would not be comfortable naming my files with a .C extension if they
> really contained C++ code, so if one wants to take advantage of SDV in
> that case, one must rename.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
I believe you can continue to use the C++ compiler by adding a compile
switch of /TP in your SOURCES and retaining the .C extension. I remember
running into this sometime back and used the compile switch.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Wade
Sent: Thursday, January 13, 2011 4:45 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Static Driver Verifier and C++?
I have been coding my driver using KMDF and my source file ends in .cpp. I
am not using classes, etc., but I believe this is the standard way of
developing, right? But when I try to use the Static Driver Verifier I get
the error: “Cannot process this driver. It has C++ code.” Should I change
the name of my file to .c?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
__________ Information from ESET Smart Security, version of virus signature
database 5788 (20110114) __________
The message was checked by ESET Smart Security.
Yes, and if you put USECXX_FLAGS=1 like Skywing mentioned, you get exactly
the same effect. That one seems to be the simplest way to get the CPP
compiler, as it’s a simple addition of one line to your sources file, not
requiring a mod to a possibly existing line.
Phil
Philip D. Barila ?(303) 776-1264
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Friday, January 14, 2011 8:34 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Static Driver Verifier and C++?
I believe you can continue to use the C++ compiler by adding a compile
switch of /TP in your SOURCES and retaining the .C extension. I remember
running into this sometime back and used the compile switch.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Wade
Sent: Thursday, January 13, 2011 4:45 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Static Driver Verifier and C++?
I have been coding my driver using KMDF and my source file ends in .cpp. I
am not using classes, etc., but I believe this is the standard way of
developing, right? But when I try to use the Static Driver Verifier I get
the error: “Cannot process this driver. It has C++ code.” Should I change
the name of my file to .c?
Ah, and… in other words… fooling SDV?
The problem is, as I said, those TINY differences between C and C++ that DO creep in to one’s code. Like, oh, I don’t know… the occasional variable declaration placed at point of use. But perhaps SDV won’t care about those.
Peter
OSR
Peter,
You are correct in that you have to make the code C. I’ve used
approaches such as the debug build uses /TP and the free build does not.
Then as I develop I build with the free build at regular intervals to
find the C++ constructs that have crept in.
I finally stopped using C++ as a better C. No argument that it is a
better C, but with PreFast and /W4 on the compile line I find all the
errors that the C++ compiler will find.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@osr.com” wrote in message news:xxxxx@ntdev:
>
>
> Ah, and… in other words… fooling SDV?
>
> The problem is, as I said, those TINY differences between C and C++ that DO creep in to one’s code. Like, oh, I don’t know… the occasional variable declaration placed at point of use. But perhaps SDV won’t care about those.
>
> Peter
> OSR
Has SDV ever actually done anyone any good here?
Mark Roddy
On Sat, Jan 15, 2011 at 10:08 AM, Don Burn wrote:
> Peter,
>
> ? You are correct in that you have to make the code C. ?I’ve used approaches
> such as the debug build uses /TP and the free build does not. ?Then as I
> develop I build with the free build at regular intervals to find the C++
> constructs that have crept in.
>
> ? I finally stopped using C++ as a better C. ?No argument that it is a
> better C, but with PreFast and /W4 on the compile line I find all the errors
> that the C++ compiler will find.
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> “xxxxx@osr.com” wrote in message news:xxxxx@ntdev:
>
>>
>>
>> Ah, and… in other words… fooling SDV?
>>
>> The problem is, as I said, those TINY differences between C and C++ that
>> DO creep in to one’s code. Like, oh, I don’t know… the occasional variable
>> declaration placed at point of use. ?But perhaps SDV won’t care about those.
>>
>> Peter
>> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>