Probleme bei Code Portierung von C# nach Java [Gelöst]

[Dandro]

Guten Tag 🙂

Ich wage mich seit einigen Tagen an Java, klappt bisher auch wirklich gut. Doch jetzt
bin ich an meine Grenzen gelangt, und hoffe dass mir hier jemand helfen kann.

Ich portiere gerade diverse Abschnitte von C# nach Java, wobei ich natürlich die
Datentypen beachte, die ja in Java alle (außer char) Vorzeichenbehaftet sind,
bei C# aber nicht alle (Vor allem der normale typ "byte" nicht).

Ich poste zuerst einmal die beiden Codeabschnitte und erzähle, was ich mir dabei gedacht habe.

Java

short one = 0x7E;
short two = 0x7E;
		
int i = 0;
int len = i + (m_raw.length - 2);
		
while (i < len) {
	one += (short)(m_raw[i++] & 0xFF);
	one = (short)(one & 0xFF); //Damit das "byte" auch ein "byte" bleibt, und nicht über seine Grenzen hinausschießt
	two += one;
	two = (short)(two & 0xFF); //Damit das "byte" auch ein "byte" bleibt, und nicht über seine Grenzen hinausschießt
}
		
int checksum = (int)(two - ((one + two) << 8)) & 0xFFFF; //Damit es ein "short" ohne vorzeichen ist

C#

byte val1 = 0x7E;
byte val2 = 0x7E;
int i = 0;
int len = i+(pak.Length-2);

while (i < len)
{
	val1 += pak[i++];
	val2 += val1;
}
ushort checksum = (ushort)(val2 - ((val1 + val2) << 8));

Also zuersteinmal sei gesagt, dass m_raw[] und pak[] bei beiden Sprachen vom typ byte[] sind. Weshalb ich
bei Java auch mit "& 0xFF" das jeweilige auszulesende Byte als vorzeichenloses darstelle. Dazu habe ich jeweils
den nächstgrößeren Datentyp gewählt.

Nunja, das Ergebnis "checksum" unterscheidet sich allerdings. Und ab hier sehe ich den Wald vor lauter Bäumen nicht. Ich hoffe ihr habt eine Idee, die mir helfen könnte.

🙂

 

[Marco13]

Naja - die bytes sind ja erstmal negativ. Daran ändert auch das verUNDen mit 0xFF nichts. Hab jetzt nicht den kompletten code nachvollzogen, und weiß nicht, ob es noch eine andere Ursache haben kann, aber du kannst mal versuchen die bytes mit

short s = (short)((b<0)?0xFF+b:b);

umzuwandeln - dann sollten auch die Vorzeichen stimmen. Analog dann für die shorts (die ints werden)

int i = (int)((s<0)?0xFFFF+s:s);

EDIT: Ähhhmm ???:L kann aber sein, dass das gleichbedeutend mit dem verUNDen ist - sorry ist schon spät 😳

 

[Dandro]

Danke schonmal für die Antwort.
Allerdings denke ich (ohne es jetzt probiert zu haben) nicht, dass mir das hilft, denn du schlägst mir vor,
dass ich dass jeweilige Byte mit 0xFF addiere, falls es negativ ist, und falls nicht es so belasse. Aber z.B in diesem Fall

two = (short)(two & 0xFF);

ist two in Java ein vorzeichenbehaftetes short, in C# allerdings ein vorzeichenloses byte. Two schießt bei der Addition mit One aber hundertprozentig über seine "Grenze" von 255 hinaus, weil es ja in Wirklichkeit ein short ist. Damit gehe ich also sicher, dass es ein byte bleibt, oder?
Ich weiß leider gerade nicht aus dem stehgreif wie sich ein byte in C# verhält wenn es über seine Grenzen hinaus addiert wird.

 

[SnooP]

Also ob eine Zahl negativ ist oder nicht, ist bei vorzeichenbehaftet/-los eigentlich egal, in dem Sinne, dass eine Verundung mit 0xFF oder 0xFFFF eigentlich korrekt ist. Die Idee ist ja, dass die binäre Darstellung identisch ist, nur die Interpretation davon nicht. Ergo der Ansatz ist richtig.

Das mit dem Überlaufen sollte in C# auch nach den entsprechenden IEEE Regeln gehn - sprich: es wird unten wieder angefangen zu zählen 😉

Ich hab letztens ebenfalls eine checksumme aus C nach Java portiert und genau die gleichen Sachen machen müssen - erstmal würde ich immer den int bevorzugen, da man sich dann das lästige rumcasten sparen kann und dann wäre gut zu wissen, was denn rauskommen soll 😉 - dann könnte ich jetzt vielleicht auch gucken woher die differenz kommt.

 

[Dandro]

Es kommen immer unterschiedliche Checksummen raus, da das ganze in einer Funktion liegt, werden immer die Checksummen verschiedener byte[] Arrays berechnet! Ich werde gleich (erstmal richtig aufstehen) einmal ein Beispiel Array posten, und die dazugehörige Checksumme, die rauskommen sollte.

<edit>
Ich hab durch nochmalige sorgfältige überprüfung der Arrays herausgefunden, dass sich die beiden Arrays jeweils unterschieden haben, was nicht an der Checksum() lag, sondern an einer Stelle kurz davor, an der die Arrays gebildet werden. Das hängt komischerweise mit einer Besonderheit der InputStreams zusammen, wie mir scheint. Undzwar scheint es so, dass vor dem ersten read() zugriff, die internen variablen "pos" und "count" nicht richtig initialisiert werden, wodurch eine Funktion "byte[] copyFrom(int len)" die eine Methode einer eigenen Subklasse von InputStream ist nicht richtig funktioniert BEVOR der erste read() Zugriff geschehen ist, danach funktioniert diese Methode einwandfrei.

Die Checksum() war allerdings korrekt, trotzdem danke für eure Hilfe.
</edit>