(Erledigt)[C++] "*cook++"?/des Verschlüsselung/vnc Passwort

[chaosben]

Heute mal eine Frage an die C-Spezies unter euch:

Was bedeutet der Zugriff auf *cook++ ?
Ok, den Stern kapiere ich noch. Der dereferenziert den Pointer und ich bekommen den Inhalt.
Aber auf was wird das ++ angewendet? Auf den zurückgegebenen Wert oder auf den Pointer selbst?

Ich brauch das, weil ich grad eine C-Datei (d3des-Verschlüsselung) in Pascal übersetze. Wenn ihr mir schön helft, bekommt ihr dann die Unit. *erpress* ;)

[thomasw]

auf den Pointer, nach dem dereferenzieren

[chaosben]

mann ... das ging ja schnell ... danke!

[Robert Marquardt]

Auf den zurueckgegebenen Wert wird ein Postincrement nie angewendet.
(*cook)++ und *cook++ liefern den gleichen Wert. Bei (*cook)++ ist aber danach *cook inkrementiert, waehrend *cook++ die Referenz (den Pointer) inkrementiert.

[DevilsCamp]

Und noch was zur Info:

Code:

c = 5;
a = c++; // a = 5; c = 6;

Code:

c = 5;
a = ++c; // a = 6; c = 6;

Ist ++ NACH der Variablen, so wird erst der Wert der Variablen zurückgegeben, dann erhöht.
Steht das ++ VOR der Variablen, so wird sie erst erhöht und dann der Wert zurückgegeben.

[Muetze1]

Zitat:

Zitat von DevilsCamp

Und noch was zur Info:

Code:

c = 5;
a = c++; // a = 5; c = 6;

Code:

c = 5;
a = ++c; // a = 6; c = 6;

Ist ++ NACH der Variablen, so wird erst der Wert der Variablen zurückgegeben, dann erhöht.
Steht das ++ VOR der Variablen, so wird sie erst erhöht und dann der Wert zurückgegeben.

In dem Zusammenhang muss ich aber darauf hinweisen, dass der C++Builder dies bei for() Schleifen nicht mehr entsprechend unterscheidet und unterschiedlich umsetzt, sondern immer ein Inkrement nach dem Durchlauf der Schleife macht.

Code:

for (int i=0; i < 10; i++)
  ;

Code:

for (int i=0; i < 10; ++i)
  ;

Ich kenne es von anderen Compilern auf anderen Systemen, das man mit diesem Unterschied den Zeitpunkt des Inkrement steuern konnte. Erste Schleife lief von 0 bis 9, zweite von 1 bis 9.

Vielleicht könnten zu diesem Punkt noch andere was sagen, weil es früher wichtig war und es mich recht erstaunt hatte das der BCB keinen Unterschied macht. Gab es da in den "neueren" Standards Änderungen??

[tommie-lie]

Zitat:

Zitat von Muetze1

Erste Schleife lief von 0 bis 9, zweite von 1 bis 9.

Hm, der GCC läuft bei beiden von 0 bis 9, sowohl im C99-, als auch im C89-Modus.
Ein anderes Verhalten als ein Durchlaufen von 0 bis 9 würde ich ehrlich gesagt nicht erwarten. Laut C99-Rationale war für C89 die Bearbeitung des letzten for-Arguments immer der letzte Schritt in einem Schleifendurchlauf. Eine for-Schleife wurde in eine while-Schleife umgeschrieben, die so aussah:

Code:

for (arg1; arg2; arg3)
  list;
---------
arg1;
while (arg2)
{
  list;
  arg3;
}

Es würde also jeweils eine seperate Anweisung "++i" oder eine separate Anweisung "i++" in der letzten Zeile der while-Schleife stehen.
Offensichtlich scheinen die von dir angesprochenen Compiler je nachdem, op pre- oder post-increment verwendet wird, mal 'ne while- und mal 'ne do-Schleife draus zu basteln. IMHO eigenartiges Verhalten.
Da du mit der Deklaration der Variable i innterhalb des Schleifenkopfes schon C99 implizierst, habe ich mal ein wenig im Standard gelesen:

Zitat:

Zitat von ISO WG14

The statement

Code:

for ( clause-1 ; expression-2 ; expression-3 ) statement

behaves as follows: The expression expression-2 is the controlling expression that is
evaluated before each execution of the loop body. The expression expression-3 is
evaluated as a void expression after each execution of the loop body.

Es ist jetzt also zwar nicht mehr als Umschreibung einer while-Schleife definiert, aber inhaltlich ist es so wie vorher auch, expression-3 ist das letzte, was ausgeführt wird.
Ich würde sagen, die von dir angesprochenen Compiler sind leicht defective oder implementieren irgendein anderes oder gar kein Standard-C.

[Muetze1]

Alles klar, gut zu wissen. Der entsprechende Compiler war soweit ich mich noch erinnere Turbo C 1.0 auf dem Atari. Auch betraf es noch einen anderen Compiler, wüsste aber nun nicht mehr genau welcher das war.

Und das in dem Beispiel i in der Schleife deklariert wurde kommt nur daher, dass ich es heutzutage so schreibe, daher nicht wundern. Damals wurde i natürlich früher definiert.

Vielen Dank für die Informationen und die Arbeit!

[tommie-lie]

Zitat:

Zitat von Muetze1

Der entsprechende Compiler war soweit ich mich noch erinnere Turbo C 1.0 auf dem Atari.

Hm, 1.0 deutet auf seeehr frühes Entwicklungsstadium hin ;-) Software war zwar damals noch nicht so sehr ein Bananenprodukt wie heute, aber vielleicht hat sich TC ja tatsächlich nur sehr grob am damals üblichen C orientiert. C89 wird es aber wohl noch nicht gegeben haben, daher ist das zu verzeihen. Ich meine in meinem K&R (erschienen 1977, deutsche Übersetzung von 1983 (will jemand günstig eine englische Originalausgabe loswerden? ;-)) stünde die for-Schleife auch so, wie sie später in C89 und C99 in den Standard gegossen wurde, also mit der Bearbeitung des dritten Arguments nach allem anderen.

Zitat:

Zitat von Muetze1

Und das in dem Beispiel i in der Schleife deklariert wurde kommt nur daher, dass ich es heutzutage so schreibe, daher nicht wundern.

Ich weiß, ich auch ;-) C89 hat sowas nur nicht mitgemacht. In C99 hat das Deklarieren von i im Schleifenkopf und das Deklarieren vor dem Schleifenkopf übrigens unterschiedliche Bedeutungen. Deklariert man's im Schleifenkopf, ist der Scope der Variable auch nur die Schleife selbst, danach ist die Variable (bei vollständiger Implementierung von C99, was kaum ein Compiler machen dürfte) nicht mehr zugänglich (zufällig im C99 gefunden, was ein Stöbern im Standard doch so alles an Interessanten Informationen bringt, die man sonst aus den Compiler-Fehlern herausinterpretieren müsste... :mrgreen:).

[chaosben]

Danke danke ... und wie versprochen gibts hier die fertige Unit. Sie is dazu gedacht um das VNC-Passwort zu ver-/entschlüsseln.

[tommie-lie]

Zitat:

Zitat von chaosben

Danke danke ...

Soll das eine Aufforderung sein, daß wir endlich mit der Fachsimpelei aufhören sollen? :mrgreen:

Hm, deine Unit sieht sehr nach einer C-Übersetzung aus.
Beispelsweise schon in der ersten Funktion cpkey():

Delphi-Quellcode:

procedure cpkey(into : PLongWord);
var
  from, endp : PLongWord;
begin
  from:=@KnL;
  endp:=@KnL[31];
  while (Integer(from)<=Integer(endp)) do
  begin
    into^:=from^;
    Inc(into);
    Inc(from);
  end;
end;

Wäre es da nicht sinnvoller, etwas daraus zu schustern, was mehr nach Pascal aussieht und für Pascal-Puristen die Lesbarkeit etwas erhöht? Beispielsweise:

Delphi-Quellcode:

procedure cpkey(var into: array of LongWord);
// oder passender selbstdefinierter Array-Typ, ich habe
// mir die Unit nicht so genau angesehen um zu wissen,
// ob ein Array mit statischer Länger hier sinnvoller
// wäre als ein Open Array
var
  i: Integer;
begin
  for i := 0 to 31 do
    into[i] := KnL[i];
end;

Iss kürzer, spart Variablen auf'm Stack und liest sich einfach besser, wenn man C-Code nicht gewöhnt ist.
Wenn in C Pointer übergeben werden, in die die Funktion Werte schreibt, kann man das sehr oft mit einem einfachen var-Parameter nach Pascal übersetzen. Dadurch verwirrt man Leser nicht mit unnötiger Pointerarithmetik.
Ich habe mir die restlichen Funktionen nicht genauer angeschaut, aber auf den ersten Blick würde ich sagen, daß man viele Dinge auf ähnliche Art und Weise mehr pascalisifizieren könnte.
Außerdem ist mir bei deinen Arrays aufgefallen, daß das Array ByteBit aus Words besteht, obwohl die Werte nur Byte-Länge haben. Hat das einen Grund?

[chaosben]

Na Holla die WaldFee ... da passt aber einer auf. Danke für die Tips.

Was die Pascalifizierung angeht: Ich hab mich bemüht eng an der Struktur der C-Datei zu bleiben, damit das Debuggen leichter fällt und eventuelle Änderungen leichter übernommen werden können. Ersteres hat sich schon bezahlt gemacht, denn wir mussten die Unit an 2 Rechnern debuggen. Der ein hatte die C-Datei geladen, der andere die Pascal-Unit. Daurch die gleiche Struktur konnten wir Zeile für Zeile durchgehen und den Fehler finden.

Was das Array angeht: Ja, an sich hast du Recht. Nur: wenn ich anfangen die Unit zu "tunen" kann sie ein anderer vielleicht nicht mehr so leicht verstehen, wenn er den C-Code daneben liegen hat... naja ... es läuft auf obiges hinaus. Natürlich kannst du dir die Unit passend und schöner machen und sie als Konkurrenz-Produkt posten. ;)

[tommie-lie]

Zitat:

Zitat von chaosben

Ich hab mich bemüht eng an der Struktur der C-Datei zu bleiben, damit das Debuggen leichter fällt und eventuelle Änderungen leichter übernommen werden können.

Das sind zwei Argumente. Ich dachte der C-Code wäre bereits stable, sodaß er sich in absehbarer Zeit nicht mehr ändert. In dem Falle bräuchte man ihn natürlich auch nicht mehr großartig debuggen. Nun stellt sich für euer Vorgehen lediglich die Frage, ob paralleles Maintainen von Quellcode in zwei verschiedenen Sprachen sinnvoll ist, oder ob man sich nicht lieber auf eine Sprache beschränkt, den Krempel in 'ne DLL kompiliert und dann unabhängig jeder (unabhängig von der Sprache) die Funktionen daraus aufrufen und benutzen kann.
Ich kenne Übersetzungen halt nur als Mittel, um etwas für Leser beider Weltanschau^WSprachen zugänglich zu machen, nicht um zweimal möglichst identischen Quellcode zu maintainen ;-)

Zitat:

Zitat von chaosben

Natürlich kannst du dir die Unit passend und schöner machen und sie als Konkurrenz-Produkt posten. ;)

Hihi, ne, so viel Langeweile habe ich dann auch wieder nicht :mrgreen:

[chaosben]

Hier noch mal eine gefixte Version.