Am 14.03.2021 um 15:24 hat Nico Mayer geschrieben:
Der Codeabschnitt sollte eigentlich wie die "max_neg"-Lösung funktionieren.
Mein zentraler Gedanke von diesem Codeabschitt war, dass das Bitmuster der
Zahl durch die "signed->unsigned" Konvertierung" nicht geändert wird.
Daher:
(unsigned long long)LONG_MIN == 0x80000000
Das hier ist nicht richtig. Du bekommst Sign Extension und damit:
(unsigned long long) LONG_MIN == ffffffff80000000
Wenn du das ganze auf deinem x86_64-Rechner probiert hast, kriegst du
das Problem nicht, weil long da schon 64 Bit ist. Aber auf i386 geht das
schief.
Der vollständigkeit halber, im C-Standard ist das so definiert, kommt
aber aufs selbe raus:
Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value
that can be represented in the new type until the value is in the
range of the new type.60)
(unsigned long long)LLONG_MIN == 0x8000000000000000
Jetzt verstehe ich nicht ganz, wie du in deinem Review die Obergrenzen
berechnest. Warum wird das jeweilige Minimum von ULLONG_MAX abgezogen?
Die Testfälle werde ich nochmal überprüfen. Vielleicht auch ganz cool wäre
hier die Nutzung von Gcov. So könnte man bestimmen, wie gut getestet wird.
Meine Rechnung in der letzten Mail war off by one, aber macht es jetzt
mehr Sinn für dich?
Kevin