Deutsches Lazarusforum

Der Fehler ist schon behoben. https://github.com/libsdl-org/SDL/issues/9544 Sie habe es ein wenig anders gelöst als in meinem Vorschlag. Die haben ein Doppel not gemacht. enabled = !!enabled; // make sure this is definitely either SDL_TRUE or SDL_FALSE. Da sieht man wieder die Vorteile von Opensourc...

Das Problem hierbei ist das Bitwise Operationen in Pascal eher Mäßig umgesetzt wurden (sollten ja Ursprünglich gar nicht Teil der Sprache sein, wurde ja Nachträglich hinzugefügt), und damit hier uneindeutigkeiten entstehen. Wen man rein Pascal codet ist dies auch kein Problem. Wie du schon schreibt...

Ich vermute ich habe den Fehler gesehen. In dieser Routine werden 2 Booleans verglichen, welche als int deklariert sind. Obwohl der Eingabe bool True ist und der der vergleichswert dies auch ist, sind sie trozdem unterschiedlich. Ich habe den Fehler gefunden. void SDL_SetEventEnabled(Uint32 type, S...

Wahrscheinlich verwendet die irgendein Array mit zwei Elementen je nach Wert des Parameters. Ist natürlich recht dumm, wenn man keine ordentliche Validierung der Parameter macht... In dem Fall wäre womöglich tatsächlich die Nutzung der BooleanX-Typen richtiger... :roll: Ich vermute ich habe den Feh...

Ich nutze ja immer die Unit "ctypes", da gibt es dann einen CBool, dann muss man sich nichts selbst ausdenken ... Auch da kann man stolpern. Der "cbool" funktioniert hier gut, wen es ein echter "bool "ist. Und der ist 32bit. extern void test( bool b); Hier könnte es Probleme geben, da er nur 8Bit i...

Ganz konkret habe ich mir mal gl.pp angeschaut und da sind GL_TRUE und GL_FALSE definiert als... Genau dort sind sie wie in vielen C-Libs mit 0 und 1 definiert. Jetzt habe ich gerade noch was dümmeres entdeckt. In der veralteten unit SDL welche bei FPC dabei ist. type SDL_Bool = (SDL_FALSE, SDL_TRU...

Ich bin gerade über eine Falle gestolpert. Bei libs welche auf C-Bibliotheken zugreifen, werden vielfache eigene Booleans definiert. Die gl Unit ist ein gutes Beispiel dafür. Das not funktioniert nicht richtig mit denen. uses gl; begin WriteLn(GL_TRUE); // -> 1 WriteLn(GL_FALSE); // ->01 WriteLn(); ...

Natürlich, bei mir auch nicht. Darum steht es ja auf der Wunschliste.

Jetzt habe ich verstanden.

Bei OpenGL wäre es ein Vorteil bei Matrizen. Wen man sie deklariert und sie wäre schon auf Identity gesetzt.

Was noch echt cool wäre, wen es sowas in dieser Art geben würde: type Tvec=array[0..2] of Single = default(1, 0, 0); var vec:Tvec; Auf meiner Wunschliste wäre, das "Default" direkt bei der deklaration einsetzen zu können: type TData = record Name: String; X, Y: Integer; Description: String; end; va...

Bei "Data: array[0..255] of byte" geht das nicht, da würde ich auf den Hint rechts-klicken und die Option zum Ignorieren der Meldung auswählen.

Schon wieder was neues gelernt, das mit den Rechtsklick kannte ich nicht, habe bis jetzt immer manuell das {%H-} eingefügt.

Wenn "array[0..255] of byte" ein eigener Typ wäre, z.B. TByteArray256, dann könnte man das Folgende machen: type TByteArray256 = array[0..255] of Byte; var Data: TByteArray256; begin Data := Default(TByteArray256); FillByte(Data, SizeOf(Data), 0); Könnte man da nicht das FillChar weglassen, ausser ...

Benutzt Du eventuell eine deutlich ältere FPC-Version?

Nein, eine brandneu.

Wieso kommt hier folgende Warnung ? Ich initialisiere doch Data mit FillByte.

und das solltest du im Bugtracker melden,

https://gitlab.com/freepascal.org/fpc/s ... sues/40727

Ich habe noch was festgestellt , der Fehler tritt nur bei (-O4) auf.

So habe es nun auf ein Minimum abgespeckt, ich habe sogar sämtliche LCL-Zeugs entfernt. Aber etwas muss doch noch anders sein, als wen ich ein neues "Einfaches Programm" erstelle. Wen ich dies mache und die Plattform umstelle, läuft dieses dann. Daher bitte das Programm in Anhang als Referenz verwen...