Bereichsüberlauf bei Funktion IsAdmin

[himitsu]

Und in welcher Zeile genau kommt dieser Fehler?

Nja, viele Codes sind "der Einfachheit halber" so programmiert, daß sie absichtlich "Überläufe" ausnutzen (z.B. die meisten CRC/Hash-Berechnungscodes).
Dazu zählt auch, daß oftmals Integer an Cardinal und umgekehrt übergeben werden, was von den Bits her zwar paßt, aber wenn nun genau auf den Zahlenbereich geachtet wird, dann paßt es eben nicht mehr.

Du hast jedenfalls global in deinen Projektoptionen die Überlaufprüfung aktiviert und nun knallt es natürlich, da sich diese Einstellung nun auf alle kompilierten Codes auswirkt.

(OK, bei "absichtlichen" Überläufen wäre es da halt besser, wenn an diesen Stellen diese Prüfung auch geziehlt deaktiviert würde, damit wowas nicht passiert)

[Dalai]

Zitat von himitsu:

Und in welcher Zeile genau kommt dieser Fehler?

Ups, wusste ich doch, dass ich was vergessen hab. Der Aufruf der Funktion EqalSid() löst die Exception aus (beim zweiten Durchlauf der for-Schleife).

Zitat:

Du hast jedenfalls global in deinen Projektoptionen die Überlaufprüfung aktiviert und nun knallt es natürlich, da sich diese Einstellung nun auf alle kompilierten Codes auswirkt.

Der Witz war ja, dass ich ein neues Projekt erzeugt habe und darin war keine Bereichsprüfung aktiviert. Die hab ich erst aktiviert, nachdem der Debugger die Exception fing.

Wichtige Ergänzung: Ich meine die Bereichsprüfung ($R), nicht die Überlaufprüfung ($Q)!

MfG Dalai

[Uwe Raabe]

Schau mal:

Delphi-Quellcode:

  _TOKEN_GROUPS = record
    GroupCount: DWORD;
    Groups: array[0..0] of TSIDAndAttributes;
  end;

Sowas geht nur ohne Bereichsprüfung (wenn GroupCount > 1).

[Dalai]

OK, das erklärt das Problem, nur habe ich die Bereichsprüfung in den Projektoptionen erst eingeschaltet, nachdem der Debugger die Exception beim ersten Ausführen gefangen hatte. Das ist es, was ich nicht verstehe.

Inzwischen habe ich etwas festgestellt, was erklärt, warum in den bisherigen Projekten das Problem von selbst verschwand: man muss das komplette Projekt neu erstellen lassen, um die Umschaltung der Bereichsprüfung wirken zu lassen, einfaches Kompilieren (Strg+F9) oder Ausführen (F9) genügt nicht. Die anderen Projekte habe ich öfter mal komplett neu erzeugen lassen, bei diesem war das bislang nicht weiter notwendig.

@Uwe Raabe: Danke für die Info. Jetzt weiß ich wenigstens, dass die Funktion selbst passt (hätte ja sein können, dass darin etwas hochohmig ist).

[OT]
Zusatzfrage, weil ich das jetzt schon mehrfach gesehen habe: Was ist denn ein array[0..0] of Typ ? Dass das Feld nur ein Element hat, kann ich mir denken, aber warum dieses Konstrukt?
[/OT]

MfG Dalai

[himitsu]

Das ist eine Abwandlung von C/C++.
Da gibt es Arrays der Länge 0, was sich in Delphi aber so nicht definieren läßt, da in Delphi nicht die Länge, sondern der Bereich angegeben wird und da die Länge mindestens 1 ist.
Man hat sich quasi darauf geeinigt, daß diese Array[0..0] ein statisches Array ohne Längenbegrenzung darstellen.

Mir war mal so, als hätte man bei diesen Arrays die Bereichsprüfung deaktiviert, was sich leider als falsch erwiesen hat.


Bei einem neueren Delphi hättest du {$IFOPT Q+} gehabt, um nach dem deaktivieren des {$Q+} dieses wieder aktivieren zu können.
Nja, du kannst aber immernoch, an den Anfang dieser Unit ein {$Q-} schreiben und gut ist.

Delphi-Quellcode:

{$IFOPT R+}
  {$MESSAGE Warn 'Mit Bereichsprüfung compiliert'}
{$ENDIF}


{$UNDEF _Q}{$IFOPT Q+}{$DEFINE _Q}{$ENDIF}
mach_was_ohne_Bereichsprüfung;
{$IFDEF _Q}{$Q+}{$ENDIF}