Dieser Fehler tritt nur auf, wenn ich mit dem WinDDK nmake Compiler in 'free' (release), der Optimierungen durchführt, baue. Ich kann nicht reproduzieren dies in der "überprüft" Build oder Kompilieren mit VS.
Hier ist ein Pseudocode, der zeigt, was in meinem Code passiert:
main()
{
//variable init and other code
fprintf(log, "pre nullValue: %lu\n", NULL); //printf added for debugging
otherFunc();
funcWithError(str1, str2, NULL);
fprintf(log, "post nullValue: %lu\n", NULL);
fprintf(log, "post2 nullValue: %lu, %lu, %lu\n", NULL, 0, NULL);
}
BOOL otherFunc()
{
//variable init and other code
callToDll();
//...doing stuff
libusb_usb_open(var1); //If I remove this line there is no problem!!
//...doing more stuff
}
BOOL funcWithError(char* s1, char* s2, FUNC_PTR fp)
{
fprintf(log, "inFunc nullValue: %lu, %lu\n", NULL, fp);
if(fp != NULL)
return FALSE; //This line is being executed erroneously!!
}
Ausgabe im Protokoll:
pre nullValue: 0
inFunc nullValue: 0, 251208
post nullWert: 251208
post2 nullValue: 251208, 251208, 251208
Hinweis: Die wiederkehrende Nummer (251208) ist bei jeder Ausführung des Programms eine andere Nummer.
Allein die Änderung dieser einen Zeile behebt/verursacht das Problem. Es ist die libusb usb_open anrufen.
- Letztlich geht es mir darum, herauszufinden, wie das Problem behoben werden kann (ich kann diesen Anruf nicht vermeiden).
- Aber nur auf einem Stack / Speicher-Management-Ebene, wie ist es überhaupt möglich, NULL nicht Null haben und haben einen literalen Wert '0' als nicht Null drucken?
Lassen Sie mich wissen, welche weiteren Informationen hilfreich sein könnten...