Encodieren und Decodieren

Moin alle sammt!
Der gute alte Caesar hatte damals ja schon diese tolle Idee das Alphabet in einer anderen Reihenfolge aufzuschreiben und so Nachrichten zu verschlüsseln. An sich sollte dieses Verfahren mit dem Computer leicht zu realisieren sein.
Man nehme eine ASCII-Tabelle, bringt sie mit std::random_shuffle() durcheinander und schreibt seinen Text durch diese Tabelle.
Um den enstandenen Text wieder leserlich zumachen, braucht man die inverse Tabelle.
Beispiel:

original  codiert   invers
1 2 3      2 7 4    8 1 5
4 5 6      9 3 8    3 7 9
7 8 9      5 1 6    2 6 4

Wenn ich den Text 123 durch die codierte Tabelle schreibe, kommt 274 raus.
Schreibe ich diese Zahl (274) dann durch die inverse Tabelle kommt wieder 123 bei raus.

Im Prinzip müsste das doch so funktionieren, oder?

Bashar

Ja.

Gut! Dann frage ich mich, warum dieser Code zum Decodieren nicht funzt.

char* decrypt(int initwert, const char* str, int strlength)
{
    // init ascii, tmp
    char tmp[256];
    char ascii[256];
    for(int i=0; i<256; ++i)
        tmp[i] = i;

    // shuffle tmp
    srand(initwert);
    std::random_shuffle(tmp, tmp+256);

    // inverse tmp and save to ascii
    for(int i=0; i<256; ++i)  // wieso durchläuft er diese schleife nur 128 mal?
        ascii[tmp[i]] = i;

    // decode string
    char* result = new char[strlength];
    for(int i=0; i<strlength; ++i)
        result[i] = ascii[str[i]];

    return result;
}

groovemaster

char hat einen Wertebereich von -128..+127. Dh in deiner Funktion erfolgen ungültige Speicherzugriffe.

DennisB schrieb:

// inverse tmp and save to ascii
    for(int i=0; i<256; ++i)  // wieso durchläuft er diese schleife nur 128 mal?
        ascii[tmp[i]] = i;

Hier kann theoretisch folgendes passieren:

ascii[-10] = i;

Nicht nur, dass dies falsch ist, hier kann das Programm auch abschmieren.
Solche Sachen passieren, wenn man nicht auf signed/unsigned mismatch bzw. data truncation achtet (was man leider viel zu oft in diversen Projekten sieht [ironie]sind ja nur Warnungen und keine Fehler[/ironie]).

Gut gesagt: Sind ja nur Warnungen und keine Fehler!
Der MinGW hat mir garnichts angezeigt, weder Warnung noch Fehler. Ich achte gerade in meinen Projekten darauf, dass nicht mal Warnungen auftreten.
Danke für die Hilfe. Daran hatte ich garnicht gedacht.

Gerard

groovemaster2002 schrieb:

char hat einen Wertebereich von -128..+127. Dh in deiner Funktion erfolgen ungültige Speicherzugriffe.

AFIK ist es nicht definiert ob char signed oder unsigned ist

Noch ein Grund, weshalb darauf acht gegeben werden sollte.

groovemaster

Gerard schrieb:

AFIK ist es nicht definiert ob char signed oder unsigned ist

Da hast du absolut recht ( ISO/IEC 14882:1998(E) - 3.9.1 Fundamental types). Nur hab ich noch keinen Compiler gesehen der by default nicht signed ist. Ausser du änderst das mit einem Compilerflag .

DennisB schrieb:

Der MinGW hat mir garnichts angezeigt, weder Warnung noch Fehler.

Das hängt natürlich auch immer vom verwendeten Warning-Level ab.