PureBoard

Danke für die Bestätigung!

mk-soft hat geschrieben:Ist definitiv ein Bug...

War aber schon mal für die x86 Version vor Ewigkeiten gemeldet worden.

Wo ist da ein Bug, wenn er versucht das Ergebnis von aus einem .b und einem .q in ein .b zu schreiben? Wie soll da vernünftiges rauskommen?

Josh hat geschrieben:

mk-soft hat geschrieben:Ist definitiv ein Bug...

War aber schon mal für die x86 Version vor Ewigkeiten gemeldet worden.

Wo ist da ein Bug, wenn er versucht das Ergebnis von aus einem .b und einem .q in ein .b zu schreiben? Was soll da vernünftiges rauskommen?

Sieh dir mein Beispiel von 10:02 an!
Hier schreibe ich in ein Long - und es tritt ebenfalls der Fehler auf.

Unabhängig davon arbeite ich hier auf Bitebene bei dem der Typ irrelevant ist, so lange das Ziel breit genug ist.

Ich vermute einen Fehler bei der internen Endian-Umschaltung. Hierzu müsste ich mal das Verhalten bei 64Bit testen..

techniker hat geschrieben:Sieh dir mein Beispiel von 10:02 an!
Hier schreibe ich in ein Long - und es tritt ebenfalls der Fehler auf.

Kommt 1 raus, wie erwartet. Sehe an dem Ergebnis keinen Fehler.

techniker hat geschrieben:Unabhängig davon arbeite ich hier auf Bitebene bei dem der Typ irrelevant ist, so lange das Ziel breit genug ist.

Das Ziel ist eben nicht breit genug. Was rede ich denn die ganze Zeit.

Josh hat geschrieben: Kommt 1 raus, wie erwartet. Sehe an dem Ergebnis keinen Fehler.

Hast auch mal den Datentyp von Variable b geändert und durch den x86-Compiler gejagt?

Josh hat geschrieben:Das Ziel ist eben nicht breit genug. Was rede ich denn die ganze Zeit.

Du verstehst es nicht..?!? Es betrifft bei x86 nur den Typ Quad!

Es hat nichts mit der breite des Ziels zu tun, da sowieso nur das LSB weitergegeben - der Rest wird verworfen!
(und dabei ist/sollte es egal (sein), ob 1 Bit oder 63Bit verworfen werden).

techniker hat geschrieben:Hast auch mal den Datentyp von Variable b geändert und durch den x86-Compiler gejagt?

Wenn du den Datentyp von b auf .q änderst, dann musst du natürlich die Ergebnisvariable c auch auf .q ändern und alles ist ok.

techniker hat geschrieben:Du verstehst es nicht..?!? Es betrifft bei x86 nur den Typ Quad!

Es hat nichts mit der breite des Ziels zu tun, da sowieso nur das LSB weitergegeben - der Rest wird verworfen!
(und dabei ist/sollte es egal (sein), ob 1 Bit oder 63Bit verworfen werden).

Nein, du verstehst es nicht, wie man ja an obigen Punkt sieht. Da willst du wieder ein .q in ein .l schreiben und wunderst dich, dass Blödsinn raus kommt.


Noch mal, wenn du einen falschen Code schreibst und das Ergebnis in machen Fällen trotzdem richtig ist, heißt das noch lange nicht, dass dein Code deswegen richtig ist. Lies dir bitte noch mal mein Zitat aus der Hilfe in meinem ersten Betrag durch. Damit ist eigentlich alles gesagt.

Josh hat geschrieben:Lies dir bitte noch mal mein Zitat aus der Hilfe in meinem ersten Betrag durch. Damit ist eigentlich alles gesagt.

Das Zitat sagt nur aus, dass eine Bitoperation ohne Zielzuweisung das Ergebnis in die erste (linke) Variable ablegt. Nicht mehr und nicht weniger.
Das hat absolut nichts mit der breite des Datentyps zu tun. Derartige Operationen sind in anderen Sprachen (z.B. C) ebenfalls üblich, zulässig und liefern das korrekte Ergebnis. Nur hier bei der Benutzung von Quad und dem x86-Compiler nicht..!

techniker hat geschrieben:Das Zitat sagt nur aus, dass eine Bitoperation ohne Zielzuweisung das Ergebnis in die erste (linke) Variable ablegt. Nicht mehr und nicht weniger.
Das hat absolut nichts mit der breite des Datentyps zu tun. Derartige Operationen sind in anderen Sprachen (z.B. C) ebenfalls üblich, zulässig und liefern das korrekte Ergebnis. Nur hier bei der Benutzung von Quad und dem x86-Compiler nicht..!

Natürlich hat das was mit der Breite des Datentyps zu tun. Wenn deine erste (linke) Variable ein .b ist, dann kannst du nicht erwarten, dass diese mit einem .q umgehen kann.
Genau das gleiche wenn du eine Ergebnisvariable vom Typ l. hast, dann kannst du auch nicht erwarten, dass diese mit einem .q umgehen kann.

Josh hat geschrieben:Natürlich hat das was mit der Breite des Datentyps zu tun. Wenn deine erste (linke) Variable ein .b ist, dann kannst du nicht erwarten, dass diese mit einem .q umgehen kann.
Genau das gleiche wenn du eine Ergebnisvariable vom Typ l. hast, dann kannst du auch nicht erwarten, dass diese mit einem .q umgehen kann.

Wo steht das?

Bzw. wie Caste ich den Typ dann mit PB?
Wenn dies wirklich so sein sollte, dann ist dies ein gravierender Nachteil (und meiner Ansicht nach ein Bug) von PB, das ich so noch nie bei einer anderen Sprache gesehen habe!