4. Logisches Problem?

Logisches Problem?

  • ?

    Wieso kehrt meine Funktion mit false zurück, obwohl (100 mal geprüft) (DWORD) ValidCompilation > (DWORD) TrampolineProc > (DWORD) NewWindowProc ???
    Was bedeutet das @ILT+x ? Würde der Compieler den waren Wert von NewWindowProc / TrampolineProc ins ecx Register schreiben, würde es funktionieren !?

    Debugger:

    95: //Überprüft die Kompilierung
    96: bool ValidCompilation()
    97: {
    100014F0 55 push ebp
    100014F1 8B EC mov ebp,esp
    100014F3 83 EC 40 sub esp,40h
    100014F6 53 push ebx
    100014F7 56 push esi
    100014F8 57 push edi
    100014F9 8D 7D C0 lea edi,[ebp-40h]
    100014FC B9 10 00 00 00 mov ecx,10h
    10001501 B8 CC CC CC CC mov eax,0CCCCCCCCh
    10001506 F3 AB rep stos dword ptr [edi]
    98: if(((DWORD) ValidCompilation > (DWORD) TrampolineProc)
    99: && ((DWORD) TrampolineProc > (DWORD) NewWindowProc))
    10001508 B8 19 10 00 10 mov eax,offset @ILT+20(ValidCompilation) (10001019)
    1000150D 3D 05 10 00 10 cmp eax,offset @ILT+0(TrampolineProc) (10001005)
    10001512 76 11 jbe ValidCompilation+35h (10001525)
    10001514 B9 05 10 00 10 mov ecx,offset @ILT+0(TrampolineProc) (10001005)
    10001519 81 F9 1E 10 00 10 cmp ecx,offset @ILT+25(NewWindowProc) (1000101e)
    1000151F 76 04 jbe ValidCompilation+35h (10001525)
    100: {
    101: return true;
    10001521 B0 01 mov al,1
    10001523 EB 02 jmp ValidCompilation+37h (10001527)
    102: }
    103: return false;
    10001525 32 C0 xor al,al
    104: }

    Quellcodeabschnitt:

    bool ValidCompilation()
{
	if(((DWORD) ValidCompilation > (DWORD) TrampolineProc)
		&& ((DWORD) TrampolineProc > (DWORD) NewWindowProc))
	{
		return true;
	}
	return false;
}
    0
  • G

    Was machst du hier? Funktionsadressen vergleichen? Das ist keine gute Idee und wird zu nichts führen.
    Du hast übrigens Recht. Du hast ein logisches Problem.

    if (x > y)
    return true;
return false;

    schreibt man

    return x > y;
    0
  • ?

    a. Funktionsvergeleiche kann man so vergessen, weiß ich. Aber ich hatte das Problem und wollte das klären auch wenn es keinen Sinn gibt. Es könnte ja sein, das ein solches problem wann anders wieder auftaucht.
    b. sollte dein code das problem lösen??? was is dann bei mir falsch?

    0
  • G

    zu a)
    Wie gesagt, ein Vergleich von Funktionsadressen bringt nichts. Da es dem Compiler überlassen ist, wo er Funktionen platziert, hast du mit solchem Code mehr oder weniger undefiniertes Verhalten.
    zu b)
    Falsch ist da nichts. Du benutzt nur boolsche Logik ohne deren Anwendung wirklich verstanden zu haben.

    0
  • P

    Ganz einfach: Dein Adressvergleich ist immer falsch, das zeigt Dir schon der Debugger:

    98:       if(((DWORD) ValidCompilation > (DWORD) TrampolineProc)
99:           && ((DWORD) TrampolineProc > (DWORD) NewWindowProc))
10001508 B8 19 10 00 10       mov         eax,offset @ILT+20(ValidCompilation) (10001019)
1000150D 3D 05 10 00 10       cmp         eax,offset @ILT+0(TrampolineProc) (10001005)
10001512 76 11                jbe         ValidCompilation+35h (10001525)
10001514 B9 05 10 00 10       mov         ecx,offset @ILT+0(TrampolineProc) (10001005)
10001519 81 F9 1E 10 00 10    cmp         ecx,offset @ILT+25(NewWindowProc) (1000101e)
1000151F 76 04                jbe         ValidCompilation+35h (10001525)

    Hier sagst Du: Wenn 10001019 > 10001005 UND 10001005 > 1000101E ist, dann gib "true" zurueck, sonst "false". Da der zweite Teil immer falsch ist, ist die Bedingung nie erfuellt.

    0
  • ?

    [quote="DjFishbone"]Wieso kehrt meine Funktion mit false zurück, obwohl (100 mal geprüft) (DWORD) ValidCompilation > (DWORD) TrampolineProc > (DWORD) NewWindowProc ???
    quote]
    Also: Ich habe die boolsche Logik verstanden! Wie gesagt (und nochmal zitiert) ist TrampolinProc auf jeden Fall größer als ValidCompilation! Das habe ich mit dem Debugger geprüft, der mir die Variablen ANZEIGT. Also müsste da true rauskommen. Warum ich an diesem Beispiel festhalte habe ich bereits erkärt: Ich will keine Fragen offen stehen lassen auch wenn sich das eigentliche Problem von selbst gekärt hat.
    Nach meinem Verständnis über C++ kann ich die Adressen vergleiche, auch wenn ich dabei nicht unbedingt etwas verbnünftiges herausbekomme. Schaut doch mal in den Thread "Größe einer Funktion" von icy. Da erkärt jemand, dass man nur die Adressen von einander abzuziehen braucht um die Größe zu ermitteln. Das dieses nicht geht war mir kalr als ich im Debugger gesehen hab, das zwischen den Funktion ein großer Leerraum ist.
    Nach meinem Verständnis ist 5 > 3 && 6 > 4 WAHR ⚠

    0
  • G

    Lass es einfach bleiben, oder mach das mit Assembler. Wie ich schon sagte, das Vergleichen von Funktionen liefert undefiniertes Verhalten. Wozu brauchst du eigentlich sowas?

    0
  • ?

    Danke für deine letzte Antwort, die mir schon besser einleuchtet und generell für euer Interesse 😉

    Die Frage, warum das nicht geht lässt sich anscheinend nicht klären... 🙄

    0
  • G

    DjFishbone schrieb:

    Danke für deine letzte Antwort, die mir schon besser einleuchtet und generell für euer Interesse 😉

    Hör ich da leichten Mismut heraus? Was willst du denn noch wissen? Wurde doch schon alles beantwortet. Was das Ergebnis des Vergleichs betrifft, lies dir Power Off's Beitrag nochmal durch.

    DjFishbone schrieb:

    Wieso kehrt meine Funktion mit false zurück, obwohl (100 mal geprüft) (DWORD) ValidCompilation > (DWORD) TrampolineProc > (DWORD) NewWindowProc ???

    Das kannst du niemandem erzählen, der Debugger liefert ja immerhin andere Fakten.

    Zum Thema undefiniertes Verhalten, schau dir den C oder C++ Standard an, dann weisst du was das bedeutet.

    DjFishbone schrieb:

    Die Frage, warum das nicht geht lässt sich anscheinend nicht klären... 🙄

    Doch, wurde ja auch gemacht. Wenn's Unklarheiten gibt, dann frag nach.

    0
Anmelden zum Antworten