/fefe/ – Aus dem Changelog von LLVM 20:Clang will now more aggressively ...

[l] Aus dem Changelog von LLVM 20:Clang will now more aggressively ... Effe ## Mod Tue, 15 Apr 2025 22:33:30 GMT Nr. 153876
fefe kurze du[…].jpg
JPG 254×318 21.4k
Aus dem Changelog von LLVM 20 [0]:Clang will now more aggressively use undefined behavior on pointer addition overflow for optimization purposes. For example, a check like ptr + unsigned_offset

NEEEIIIIIN!!!!!

Das heißt: Alter Code, der versucht, Dinge richtig zu machen, und nach Overflows guckt, aber es formaljuristisch nicht korrekt macht, kriegt jetzt Sicherheitslücken übergeholfen, die vorher nicht da waren.

Glücklicherweise sind die Standardisierungsleute bei C++ gerade dabei, der Reihe nach undefined behavior aus dem Standard zu schmeißen. C wird ein paar Jahrzehnte später nachfolgen. Bis dahin wird C leider völlig irrelevant sein.

Tja, so kann man sich auch den Fuß schießen. *slow clap*

Wenn ihr solchen Code produziert habt, und euch jetzt fragt, wie man den Check korrekt formuliert: Vorher nach uintptr_t casten. Das ist zwar formaljuristisch auch falsch, denn der Standard sagt, uintptr_t ist groß genug, um einen Pointer zu halten, aber garantiert nicht, dass es nicht größer ist, was dann den Overflow verbergen würde. Aber in der Praxis ist sizeof(uintptr_t) == sizeof(void*).

[0] https://releases.llvm.org/20.1.0/tools/clang/docs/ReleaseNotes.html

https://blog.fefe.de/?ts=99001e82

[l] Felix Tue, 15 Apr 2025 23:42:03 GMT Nr. 153878
>Wenn ihr solchen Code produziert habt, und euch jetzt fragt, wie man den Check korrekt formuliert: Vorher nach uintptr_t casten. Das ist zwar formaljuristisch auch falsch, denn der Standard sagt, uintptr_t ist groß genug, um einen Pointer zu halten, aber garantiert nicht, dass es nicht größer ist, was dann den Overflow verbergen würde. Aber in der Praxis ist sizeof(uintptr_t) == sizeof(void*).
Besser auf Zeigerarithmetik gleich verzichten und stattdessen Array-Indizes verwenden. Da hat man solche Probleme nicht. Ist Zeiger zu vergleichen (außer auf Gleichheit/Ungleichheit) überhaupt "formaljuristisch" definiert? Der C-Standard sagt, soweit Felix weiß nicht, dass ein Zeiger intern überhaupt eine Zahl ist bzw. als solche repräsentiert werden kann. Es gibt auch tatsächlich, soweit Felix weiß, komische Systeme wie z.B. bestimmte Mainfraimes, die Zeiger intern irgendwie "taggen". Ein uintptr_t ist zwar so definiert, dass er groß genug ist, um einen Zeiger aufzunehmen und in einen Zeiger zurückkonvertiert zu werden, aber Felix ist sich nicht sicher, ob eine totale Ordnung darauf definiert ist. Würde das jedenfalls nicht automatisch annehmen.

[l] Felix Wed, 16 Apr 2025 00:19:52 GMT Nr. 153880
>For example, a check like ptr + unsigned_offset
Und da hat Fefe mal wieder den Effe-Bot hackiert. Im Original heißt es:
>Clang will now more aggressively use undefined behavior on pointer addition overflow for optimization purposes. For example, a check like ptr + unsigned_offset < ptr will now optimize to false, because ptr + unsigned_offset will cause undefined behavior if it overflows (or advances past the end of the object).

>und euch jetzt fragt, wie man den Check korrekt formuliert
Für i >= 0 statt if(arr + i < end) ein if(i < size) zu machen war dem Herrn 0xfefe wohl zu kompliziert. Das "bounds check immer auf den Indexen machen" hat sich doch mittlerweile (hoffentlich) rumgesprochen.

>Vorher nach uintptr_t casten. Das ist zwar formaljuristisch auch falsch, denn der Standard sagt, uintptr_t ist groß genug, um einen Pointer zu halten, aber garantiert nicht, dass es nicht größer ist, was dann den Overflow verbergen würde. Aber in der Praxis ist sizeof(uintptr_t) == sizeof(void*).
??? Was für eine Scheißidee?

[l] Felix Wed, 16 Apr 2025 08:08:42 GMT Nr. 153894
> C wird ein paar Jahrzehnte später nachfolgen.
Wieso sollte die gute Sprache C sich irgendwas von dem geistig behinderten Trittbrettfahrer C++ abschauen?

[l] Felix Wed, 16 Apr 2025 08:10:08 GMT Nr. 153895
> denn der Standard sagt, uintptr_t ist groß genug, um einen Pointer zu halten
Das kann er gar nicht sagen. Der Standard sagt nämlich gar nicht, daß ein Pointer eine Speicheradresse oder überhaupt eine Zahl sein muß. Das ist zwar bei x86 so, war historisch aber auf anderen Rechnerarchitekturen auch anders.

[l] Update Effe ## Mod Wed, 16 Apr 2025 08:46:00 GMT Nr. 153904

@@ -12,0 +13,2 @@
+[b]Update[/b]: Vorsicht beim Casten nach uintptr_t, denn dabei geht das implizite * sizeof(*ptr) verloren. Wenn das ein int* war, meint ptr + 3, dass drei ints dazugezählt werden, nicht drei Bytes. Wenn ich ptr vorher nach uintptr_t caste, dann muss man das * sizeof(int) von Hand machen.
+

[l] Felix Wed, 16 Apr 2025 09:24:19 GMT Nr. 153915
Was für ein Pfuscher ...

[l] Felix Wed, 16 Apr 2025 09:56:32 GMT Nr. 153922
>>153894
>die gute Sprache C
*pruhust*

>Wieso sollte ... C sich irgendwas von dem geistig behinderten Trittbrettfahrer C++ abschauen?
Machen das die C-Frickler nicht schon seit Jahrzehnten? Warum sollten sie ausgerechnet jetzt von dieser ~~dummen~~guten alten und erfolgreichen Tradition ablassen?

[l] Update Effe ## Mod Wed, 16 Apr 2025 10:43:55 GMT Nr. 153927

@@ -14,0 +15,2 @@
+[b]Update[/b]: Fortschritt ist möglicherweise auch bei C weiter als befürchtet [1].
+
@@ -15,0 +18 @@
+[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3529.pdf

[l] Felix Wed, 16 Apr 2025 11:44:13 GMT Nr. 153934
Stört keinen, dass "undefined behavior" nicht existiert, damit sich Compiler maximal blöd verhalten dürfen, sondern damit sie im Gegenteil das machen können, was auf der Plattform sinnvoll ist? Das ist kein "don't care" sondern ein "platform dependent".

[l] Felix Wed, 16 Apr 2025 11:55:47 GMT Nr. 153939
>>153934
Genau so ist es. Und das war historisch sehr wichtig, als verschiedene Computer noch sehr verschieden waren. Das ist jetzt für x86+ARM-Hegemonie nicht mehr so wichtig, aber es würde zukünftige Rechnerarchitekturen unnötig einschränken, wenn man da jetzt unnötig Implementierungsdetails festlegt.

[l] Update Effe ## Mod Wed, 16 Apr 2025 15:33:00 GMT Nr. 153964

@@ -1 +1,3 @@
-Aus dem Changelog von LLVM 20 [0]:Clang will now more aggressively use undefined behavior on pointer addition overflow for optimization purposes. For example, a check like ptr + unsigned_offset 
+Aus dem Changelog von LLVM 20 [0]:
+
+>Clang will now more aggressively use undefined behavior on pointer addition overflow for optimization purposes. For example, a check like ptr + unsigned_offset < ptr will now optimize to false, because ptr + unsigned_offset will cause undefined behavior if it overflows (or advances past the end of the object).

[l] Felix Wed, 16 Apr 2025 18:20:25 GMT Nr. 153970
>>153934
Das ist dann nicht undefined sondern implementation-defined. Gibt es auch, ist aber etwas anderes.

[l] Felix Wed, 16 Apr 2025 20:49:02 GMT Nr. 153982
Ich muss immer noch daran denken, wie er 2007 in gcc Mailinglisten gewinselt hat.

[l] Felix Wed, 16 Apr 2025 20:51:26 GMT Nr. 153983
Erinnerung daran, dass Fefes Käferreport im GCC-Bugzilla vom November 2024 immer noch unbeachtet rumdümpelt.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117807

[l] Felix Wed, 16 Apr 2025 22:55:59 GMT Nr. 153989
>>153934
Stört jede Menge Leute. Nur leider nicht die Leute, die Compiler schreiben, denn die wollen ja Bankmarken gewinnen.

Antwort erstellen
Säge
Betreff
Name
Kommentar
Dateien (≤ 4)
Passwort

/fefe/ – Fefes Kommentarfunktion

Antwort erstellen