MSVC 19 broken

[Wilhelm M. (wimalopaan)]

Interessante Beobachtung:

folgendes Programm

#include <stdio.h>

int main() {
  puts("A banner with the strange device 'Migicative'!");
  puts("A banner with the strange device 'Borabigate'!");
}

ergibt zweimal den ersten Text mit MSVC und `-O1` ;-)

Quelle: https://quuxplusone.github.io/blog/2022/12/31/mid-snow-and-ice

[Oliver S. (oliverso)]

Wilhelm M. schrieb:
> MSVC und `-O1`

Würde mich wundern, wenn der MSVC '-O1' versteht ;)

Ansonsten klingt das stark nach Xerox...
https://www.youtube.com/watch?v=7FeqF1-Z1g0

Oliver

[Kaj (Gast)]

Oliver S. schrieb:
> Ansonsten klingt das stark nach Xerox
Was hat der Compiler mit dem Drucker zu tun?

[Udo K. (udok)]

Oliver S. schrieb:
>> MSVC und `-O1`
>
> Würde mich wundern, wenn der MSVC '-O1' versteht ;)

Ist kein Problem, der MSVC versteht auch -O2 und -c :-)

Das mit den Strings ist aber wirklich ein Bug, der in allen Versionen 
drinnen ist.
Meine Vermutung: der MSVC macht eine Checksumme über die Strings,
und es gibt eine gewisse Wahrscheinlichkeit, dass die gleich ist, obwohl 
die Strings unterschiedlich sind.
Wenn du das Read-Only String Pooling mit -GF- ausmachst, geht es...

[Wilhelm M. (wimalopaan)]

Udo K. schrieb:
> Oliver S. schrieb:
>>> MSVC und `-O1`
>>
>> Würde mich wundern, wenn der MSVC '-O1' versteht ;)
>
> Ist kein Problem, der MSVC versteht auch -O2 und -c :-)
>
> Das mit den Strings ist aber wirklich ein Bug, der in allen Versionen
> drinnen ist.
> Meine Vermutung: der MSVC macht eine Checksumme über die Strings,
> und es gibt eine gewisse Wahrscheinlichkeit, dass die gleich ist, obwohl
> die Strings unterschiedlich sind.
> Wenn du das Read-Only String Pooling mit -GF- ausmachst, geht es...

Schön, dass Du die Quelle ins deutsche übersetzt hast ;-)

[DPA (Gast)]

Ich weiss schon, warum ich den scheiss compiler nicht verwende ;)

[Udo K. (udok)]

Wilhelm M. schrieb:
> Schön, dass Du die Quelle ins deutsche übersetzt hast ;-)

Schön, dass die Quelle mit meiner Meinung übereinstimmt :-)

[Udo K. (udok)]

DPA schrieb:
> Ich weiss schon, warum ich den scheiss compiler nicht verwende ;)

Eigentlich ist der Compiler ziemlich brauchbar.  Um den Bug zu triggern, 
musst du schon sehr lange rumprobieren, und andere Compiler haben halt 
andere Bugs...

[c-hater (Gast)]

Udo K. schrieb:

> Eigentlich ist der Compiler ziemlich brauchbar.  Um den Bug zu triggern,
> musst du schon sehr lange rumprobieren, und andere Compiler haben halt
> andere Bugs...

Oder sogar denselben (prinzipiell)... In unzähligen Sprachen und 
Compilern werden Hashes verwendet und natürlich kann man dafür genau 
solche Kollisionen konstruieren.

Ist halt ein trade-off: Je kürzer der Hash, desto effizienter wird der 
Code, aber gleichzeitig steigt halt leider auch die Gefahr von 
Kollisionen.

Niemand, der wirklich programmieren kann, wird sich darüber ernsthaft 
wundern.

[DPA (Gast)]

Entweder man nimmt einen schön langen und sicheren hash, (z.B. sha256), 
und nimmt bewusst in kauf, dass irgendwo einmal in 1 von 2^256 fällen 
oder so eine Kollision passiert, oder man checkt nicht nur den hash, 
sondern nutzt den nur für den Lookup, und check dann auch noch den 
ganzen Inhalt. (Genau darum haben hash maps üblicherweise buckets.)

Niemand, der wirklich programmieren kann, verwendet unsichere kurze 
hashes und checkt gleichzeitig nicht nochmal nach, ob es wirklich 
übereinstimmt. Das ist einfach nur falsch und unverantwortlich.

[Udo K. (udok)]

DPA schrieb:
> Niemand, der wirklich programmieren kann, verwendet unsichere kurze
> hashes und checkt gleichzeitig nicht nochmal nach, ob es wirklich
> übereinstimmt. Das ist einfach nur falsch und unverantwortlich.

Der Algorithmus ist > 30 Jahre alt.  Bisher ist es keinem aufgefallen. 
Das ist auch kein Hash für eine Tabelle, sondern das PE Exe Format 
hat(te) eine Beschränkung für die Länge der externen Symbole.
Lange Strings - die extern sichtbar sind - werden als 
"BIN_EIN_LANGER_STRING?MEIN_HASH_WERT?" oder so ähnlich kodiert.
Mehr ist da nicht dran. Wenn man nicht die modernen heute üblichen 
Optimierungen verwendet, dann schreit der Linker sowieso wegen doppelt 
definierten Symbolen...

[Rolf M. (rmagnus)]

c-hater schrieb:
> Oder sogar denselben (prinzipiell)... In unzähligen Sprachen und
> Compilern werden Hashes verwendet und natürlich kann man dafür genau
> solche Kollisionen konstruieren.
> Niemand, der wirklich programmieren kann, wird sich darüber ernsthaft
> wundern.

Klar, und genau deshalb werden normalerweise Vorkehrungen getroffen, um 
solche Kollisionen korrekt zu behandeln. Was würde wohl passieren, wenn 
Hashtabellen z.B. in einer Datenbank gerne mal das falsche Ergebnis 
zurückliefern würden, weil zwei Einträge blöderweise den selben Hash 
haben?

> Ist halt ein trade-off: Je kürzer der Hash, desto effizienter wird der
> Code, aber gleichzeitig steigt halt leider auch die Gefahr von
> Kollisionen.

Ist das deine Vorgehensweise? Abwägung, wie viele Fehler man in Kauf 
nehmen kann, um noch ein paar Bytes extra rauszuholen?

Udo K. schrieb:
> Lange Strings - die extern sichtbar sind - werden als
> "BIN_EIN_LANGER_STRING?MEIN_HASH_WERT?" oder so ähnlich kodiert.
> Mehr ist da nicht dran.

Ja, und das ist ein konzepzioneller Fehler, weil eben auch verschiedene 
Strings den selben Hash-Wert haben können und damit dann das selbe 
Symbol bekommen.

> Wenn man nicht die modernen heute üblichen Optimierungen verwendet, dann
> schreit der Linker sowieso wegen doppelt definierten Symbolen...

Wohl eher nicht, denn das hätte zur Folge, dass man in einem Program nie 
zwei gleiche String-Literals haben könnte.

[Wilhelm M. (wimalopaan)]

c-hater schrieb:
> Niemand, der wirklich programmieren kann, wird sich darüber ernsthaft
> wundern.

So ein Blödsinn ... und das von Dir (falls Du es bist).

Hashfunktionen sind meistens kollisionsbehaftet, weil sie meistens 
injektiv sind (sein müssen). In diesem Fall ist das so. Ein korrekter 
Hash-Algorithmus wird daher eine Kollisionslösungsstragie haben (meisten 
über Hash-Buckets), damit er kollisionsfrei ist.

Mir ist völlig unverständlich, wie man so einen Mist in einen Compiler 
einbauen kann bzw. aktiviert lassen kann, auch wenn es irgendwie 
abschaltbar ist.

[Nano (Gast)]

Wilhelm M. schrieb:
> Mir ist völlig unverständlich, wie man so einen Mist in einen Compiler
> einbauen kann bzw. aktiviert lassen kann, auch wenn es irgendwie
> abschaltbar ist.

Es ist eher verwunderlich, warum das die Defaulteinstellung ist, gerade 
wenn es abschaltbar ist, hätte die sichere vorsichtige Einstellung die 
Defaulteinstellung sein müssen und die unsichere die per Option 
zuschaltbare.