I fail to build the simplest Windows device driver as follows:
#include <ntifs.h>
NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path)
{
int n = memcmp(0, 0, 0);
return 0;
}
The compiler is OK but the linker is failed with error lnk2019: unresolved external symbol _memcmp referenced in function _DriverEntry@8
Now, you maybe laugh and say: “It is common if you lack the correct import library which contains memcmp.”
However, if I change the code as follows, and not add any new import library, the compiler and linker are both OK.
#include <ntifs.h>
NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path)
{
memcmp(0, 0, 0);
return 0;
}
Could you laugh again?
What’s the root cause?</ntifs.h></ntifs.h>
If the result is not used, the function call is optimized away, because the compiler knows about the funciton semantics.
@Alex, will checked-build also be optimized by the compiler?
How are you creating the driver project? You have the wrong calling convention set as the default, so I think this is not a project created by normal methods
Thx
d
Bent from my phone
From: xxxxx@gmail.commailto:xxxxx
Sent: ?9/?17/?2013 7:29 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n == memcmp(0, 0, 0);
@Alex, will checked-build also be optimized by the compiler?
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
> I fail to build the simplest Windows device driver as follows:
#include <ntifs.h>
>
> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
> reg_path)
> {
> int n = memcmp(0, 0, 0);
> return 0;
> }
>
> The compiler is OK but the linker is failed with error lnk2019: unresolved
> external symbol _memcmp referenced in function _DriverEntry@8
>
> Now, you maybe laugh and say: “It is common if you lack the correct import
> library which contains memcmp.”
>
> However, if I change the code as follows, and not add any new import
> library, the compiler and linker are both OK.
>
> #include <ntifs.h>
>
> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
> reg_path)
> {
> memcmp(0, 0, 0);
> return 0;
> }
>
> Could you laugh again?
Yep. Sure. In the first example, a function is called and it provides a
result; only the result is stored. In the second example, a function is
called and its return result is ignored. So the compiler eliminates the
function. Why? Because the call to the function does nothing, and
therefore, no external reference is created for it! So it succeeds
because it doesn’t need to resolve the (nonexistent) call to memcmp. Note
that although the function itself is not declared const (to make it
compatible with the 1975 version of the C language), the compiler knows
about it.
This is pretty elementary stuff; you can see what happens if you generate
the .cod file, and you will see that the entire generated body of the
second function is
_DriverEntry PROC
xor rax,rax
ret
_DriverEntry ENDP
>
> What’s the root cause?
Not using the return value of a meaningless function call.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
></ntifs.h></ntifs.h>
I think the compiler is using the correct calling convention as the linker
specifically complains the __cdecl decorated name _memcmp instead of
_memcmp@12.
As some suggested, I would double check the cod or lst file. memcmp can be
intrinsic’d out too.
On Tue, Sep 17, 2013 at 8:37 PM, Doron Holan wrote:
> How are you creating the driver project? You have the wrong calling
> convention set as the default, so I think this is not a project created by
> normal methods
>
> Thx
> d
>
> Bent from my phone
> ------------------------------
> From: xxxxx@gmail.com
> Sent: 9/17/2013 7:29 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n ==
> memcmp(0, 0, 0);
>
> @Alex, will checked-build also be optimized by the compiler?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
The convention for the import is correct, the internal convention (_DriverEntry@8) is clearly stdcall
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan (news)
Sent: Wednesday, September 18, 2013 2:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n == memcmp(0, 0, 0);
I think the compiler is using the correct calling convention as the linker specifically complains the __cdecl decorated name _memcmp instead of _memcmp@12.
As some suggested, I would double check the cod or lst file. memcmp can be intrinsic’d out too.
On Tue, Sep 17, 2013 at 8:37 PM, Doron Holan > wrote:
How are you creating the driver project? You have the wrong calling convention set as the default, so I think this is not a project created by normal methods
Thx
d
Bent from my phone
________________________________
From: xxxxx@gmail.commailto:xxxxx
Sent: 9/17/2013 7:29 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n == memcmp(0, 0, 0);
@Alex, will checked-build also be optimized by the compiler?
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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</mailto:xxxxx></mailto:xxxxx>
I *did* the test, and it compiles the code without any call on memcmp.
That’s why I could say with some confidence that the compiler optimized it
out of existence: I looked at the .cod file.
It ain’t rocket surgery.
joe
I think the compiler is using the correct calling convention as the linker
specifically complains the __cdecl decorated name _memcmp instead of
_memcmp@12.
As some suggested, I would double check the cod or lst file. memcmp can be
intrinsic’d out too.
On Tue, Sep 17, 2013 at 8:37 PM, Doron Holan
wrote:
>
>> How are you creating the driver project? You have the wrong calling
>> convention set as the default, so I think this is not a project created
>> by
>> normal methods
>>
>> Thx
>> d
>>
>> Bent from my phone
>> ------------------------------
>> From: xxxxx@gmail.com
>> Sent: 9/17/2013 7:29 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n ==
>> memcmp(0, 0, 0);
>>
>> @Alex, will checked-build also be optimized by the compiler?
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
@Doron, I use the source of swapBuffers to compile it under WDK 7.0.
extern “C” {
#include <ntifs.h>
}
Mark Roddy
On Tue, Sep 17, 2013 at 9:56 PM, wrote:
> I fail to build the simplest Windows device driver as follows:
>
> #include <ntifs.h>
>
> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
> reg_path)
> {
> int n = memcmp(0, 0, 0);
> return 0;
> }
>
> The compiler is OK but the linker is failed with error lnk2019: unresolved
> external symbol _memcmp referenced in function _DriverEntry@8
>
> Now, you maybe laugh and say: “It is common if you lack the correct import
> library which contains memcmp.”
>
> However, if I change the code as follows, and not add any new import
> library, the compiler and linker are both OK.
>
> #include <ntifs.h>
>
> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
> reg_path)
> {
> memcmp(0, 0, 0);
> return 0;
> }
>
> Could you laugh again?
>
> What’s the root cause?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
></ntifs.h></ntifs.h></ntifs.h>
I just try it on WinDK 8.0 compiling with VS2012 and got the same problem.
It looks quite wired to me too.
On Thu, Sep 19, 2013 at 10:40 AM, Mark Roddy wrote:
> extern “C” {
> #include <ntifs.h>
> }
>
> Mark Roddy
>
>
> On Tue, Sep 17, 2013 at 9:56 PM, wrote:
>
>> I fail to build the simplest Windows device driver as follows:
>>
>> #include <ntifs.h>
>>
>> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
>> reg_path)
>> {
>> int n = memcmp(0, 0, 0);
>> return 0;
>> }
>>
>> The compiler is OK but the linker is failed with error lnk2019:
>> unresolved external symbol _memcmp referenced in function _DriverEntry@8
>>
>> Now, you maybe laugh and say: “It is common if you lack the correct
>> import library which contains memcmp.”
>>
>> However, if I change the code as follows, and not add any new import
>> library, the compiler and linker are both OK.
>>
>> #include <ntifs.h>
>>
>> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
>> reg_path)
>> {
>> memcmp(0, 0, 0);
>> return 0;
>> }
>>
>> Could you laugh again?
>>
>> What’s the root cause?
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
></ntifs.h></ntifs.h></ntifs.h>
Isn’t there an Rtl-function for this? Did you try adding te kernel
version of the CRT library to the link.
Forget about the “it compiles and links fine if I don’t store the result”
issue; that has already been explained and dismissed.
joe
I just try it on WinDK 8.0 compiling with VS2012 and got the same problem.
It looks quite wired to me too.
On Thu, Sep 19, 2013 at 10:40 AM, Mark Roddy wrote:
>
>> extern “C” {
>> #include <ntifs.h>
>> }
>>
>> Mark Roddy
>>
>>
>> On Tue, Sep 17, 2013 at 9:56 PM, wrote:
>>
>>> I fail to build the simplest Windows device driver as follows:
>>>
>>> #include <ntifs.h>
>>>
>>> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
>>> reg_path)
>>> {
>>> int n = memcmp(0, 0, 0);
>>> return 0;
>>> }
>>>
>>> The compiler is OK but the linker is failed with error lnk2019:
>>> unresolved external symbol _memcmp referenced in function
>>> _DriverEntry@8
>>>
>>> Now, you maybe laugh and say: “It is common if you lack the correct
>>> import library which contains memcmp.”
>>>
>>> However, if I change the code as follows, and not add any new import
>>> library, the compiler and linker are both OK.
>>>
>>> #include <ntifs.h>
>>>
>>> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
>>> reg_path)
>>> {
>>> memcmp(0, 0, 0);
>>> return 0;
>>> }
>>>
>>> Could you laugh again?
>>>
>>> What’s the root cause?
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> 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
>>>
>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers 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
>>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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</ntifs.h></ntifs.h></ntifs.h>
RtlCompareMemory redirects as a define to memcmp btw
Thx
d
Bent from my phone
From: xxxxx@flounder.commailto:xxxxx
Sent: ?9/?20/?2013 7:14 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n == memcmp(0, 0, 0);
RtlCompareMemory.
joe
>> extern “C” {
>> #include <ntifs.h>
>> }
> Not necessary. It has already been established that memcmp is being
> called with the correct calling convention. Look at the namecof te
> symbol; if the extern “C” were required, the error would have been
> forv_memcmp@12. I think the OP just forgot to explicitly include the
> Kernel CRT in the link step.
> joe
>
>>
>> Mark Roddy
>>
>>
>> On Tue, Sep 17, 2013 at 9:56 PM, wrote:
>>
>>> I fail to build the simplest Windows device driver as follows:
>>>
>>> #include <ntifs.h>
>>>
>>> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
>>> reg_path)
>>> {
>>> int n = memcmp(0, 0, 0);
>>> return 0;
>>> }
>>>
>>> The compiler is OK but the linker is failed with error lnk2019:
>>> unresolved
>>> external symbol _memcmp referenced in function _DriverEntry@8
>>>
>>> Now, you maybe laugh and say: “It is common if you lack the correct
>>> import
>>> library which contains memcmp.”
>>>
>>> However, if I change the code as follows, and not add any new import
>>> library, the compiler and linker are both OK.
>>>
>>> #include <ntifs.h>
>>>
>>> NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
>>> reg_path)
>>> {
>>> memcmp(0, 0, 0);
>>> return 0;
>>> }
>>>
>>> Could you laugh again?
>>>
>>> What’s the root cause?
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> 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
>>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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</ntifs.h></ntifs.h></ntifs.h></mailto:xxxxx></mailto:xxxxx>
It indeed looks like you are missing the right import library, or possibly you have the wrong calling convention for memcmp.
I think the second case with no error is the result of compiler optimization. It is probably smart enough to know that memcmp does nothing useful in this case, and simply optimized the call out of existence. You can have the compiler make a listing file and see what it generated for the procedure.
-----Original Message-----
From: xxxxx@gmail.com
Sent: Sep 17, 2013 6:56 PM
To: Windows System Software Devs Interest List
>Subject: [ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n == memcmp(0, 0, 0);
>
>I fail to build the simplest Windows device driver as follows:
>
>#include <ntifs.h>
>
>NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path)
>{
> int n = memcmp(0, 0, 0);
> return 0;
>}
>
>The compiler is OK but the linker is failed with error lnk2019: unresolved external symbol _memcmp referenced in function _DriverEntry@8
>
>Now, you maybe laugh and say: “It is common if you lack the correct import library which contains memcmp.”
>
>However, if I change the code as follows, and not add any new import library, the compiler and linker are both OK.
>
>#include <ntifs.h>
>
>NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path)
>{
> memcmp(0, 0, 0);
> return 0;
>}
>
>Could you laugh again?
>
>What’s the root cause?
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
>OSR is HIRING!! See http://www.osr.com/careers
>
>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</ntifs.h></ntifs.h>
yes, it is strange, as n is local variable and not used after set, so in
the following code, the call to memcmp should also be optimized (or deleted)
NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path)
{
int n = memcmp(0, 0, 0);
return 0;
}
2013/9/21
> As far as I can tell
> 1) The calling convention is correct (_memcmp)
> 2) The optimizer does delete te useless cal (I tried it. It does)
> 3) The correct library s not included in the link
> joe
>
> > It indeed looks like you are missing the right import library, or
> possibly
> > you have the wrong calling convention for memcmp.
> >
> > I think the second case with no error is the result of compiler
> > optimization. It is probably smart enough to know that memcmp does
> nothing
> > useful in this case, and simply optimized the call out of existence. You
> > can have the compiler make a listing file and see what it generated for
> > the procedure.
> >
> > -----Original Message-----
> >>From: xxxxx@gmail.com
> >>Sent: Sep 17, 2013 6:56 PM
> >>To: Windows System Software Devs Interest List
> >>Subject: [ntdev] Weird Problem! memcmp(0, 0, 0); vs. int n == memcmp(0,
> >> 0, 0);
> >>
> >>I fail to build the simplest Windows device driver as follows:
> >>
> >>#include <ntifs.h>
> >>
> >>NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
> >> reg_path)
> >>{
> >> int n = memcmp(0, 0, 0);
> >> return 0;
> >>}
> >>
> >>The compiler is OK but the linker is failed with error lnk2019:
> >> unresolved external symbol _memcmp referenced in function _DriverEntry@8
> >>
> >>Now, you maybe laugh and say: “It is common if you lack the correct
> >> import library which contains memcmp.”
> >>
> >>However, if I change the code as follows, and not add any new import
> >> library, the compiler and linker are both OK.
> >>
> >>#include <ntifs.h>
> >>
> >>NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING
> >> reg_path)
> >>{
> >> memcmp(0, 0, 0);
> >> return 0;
> >>}
> >>
> >>Could you laugh again?
> >>
> >>What’s the root cause?
> >>
> >>—
> >>NTDEV is sponsored by OSR
> >>
> >>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >>
> >>OSR is HIRING!! See http://www.osr.com/careers
> >>
> >>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
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > 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
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
></ntifs.h></ntifs.h>
>yes, it is strange, as n is local variable and not used after set, so in
the following code, the call to memcmp should also be optimized (or deleted)
NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path)
{
int n = memcmp(0, 0, 0);
return 0;
}
This is due to the difference of an initialization and an assignment.
in this case the value from memcmp IS used, because it is initializing the variable. True, the variable is not later used. But as far as the compiler is concerned, this initialization counts as a use, so it isn’t deleted.
I suspect that if you modify the code as follows it will get deleted.
NTSTATUS NTAPI DriverEntry(PDRIVER_OBJECT drv_obj, PUNICODE_STRING reg_path)
{
int n;
n = memcmp(0, 0, 0);
return 0;
}