Radig Stack C-Verständnis?

[Sucher (Gast)]

Hallo

kann mir bitte jemand erklären, was dieses logische UND beim Vergleich 
zwischen zwei gleichen Operanden bewirkt?
...
//TCP DestPort mit Portanwendungsliste durchführen
while (TCP_PORT_TABLE[port_index].port && 
TCP_PORT_TABLE[port_index].port!=(htons(tcp->TCP_DestPort)))
  {
....

wäre da
...
(TCP_PORT_TABLE[port_index].port!=(htons(tcp->TCP_DestPort)))
...

ohne das && das Gleiche?

Bitte um Aufklärung.

Vielen Dank
Achim

[hallo (Gast)]

ohne das jetzt zu kennen, würde ich sagen das 0 keine gültige Port 
Nummer ist.

[Andreas B. (Gast)]

Sucher schrieb:
> kann mir bitte jemand erklären, was dieses logische UND beim Vergleich
> zwischen zwei gleichen Operanden bewirkt?

Nun ja, es bewirkt ein logisches UND. Und wieso zwei gleiche Operanden? 
Vielleicht hilft es beim Verständnis wenn extra Klammern drinstehen, so 
wie es ausgeführt wird:

while (TCP_PORT_TABLE[port_index].port && (TCP_PORT_TABLE[port_index].port != htons(tcp->TCP_DestPort)))

Sucher schrieb:
> wäre da
> ...
> (TCP_PORT_TABLE[port_index].port!=(htons(tcp->TCP_DestPort)))
> ...

Nur wenn .port niemals gleich 0 ist.

[Sucher (Gast)]

Hallo
kann fast nicht sein. Logisch verstehe ich das so, dass dass in einer 
Tabelle gesucht wird ob der RECHTE Teil ..(htons(tcp->TCP_DestPort) in 
der Tabelle steht.
In der if-Anweisung steht nur
....
{
 port_index++;
}
....

So ist die Frage: Warum läuft das while nicht ewig wenn linke und rechte 
Seite nie GLEICH sind...

MfG
Achim

[Sucher (Gast)]

Hallo,

meine letzte Antwort hat sich auf @hallo bezogen...

@Andreas B. Danke. Ich glaube jetzt habe ich es geschschnallt. Solange 
ist ist der Ausdruck  von while TRUE (Port in der Tabelle ungleich dem 
gesuchten)

TCP_PORT_TABLE[port_index].port!=(htons(tcp->TCP_DestPort)

nur wenn da Tabellenende ereicht ist wird 
TCP_PORT_TABLE[port_index].port  (FALSE bzw. 0) und die while Schleife 
wird verlassen.

Danke
Achim

[Sucher (Gast)]

Hallo

welcher Wert kommt da raus?

TCP_PORT_TABLE[port_index].port!=(htons(tcp->TCP_DestPort)

bei True= 01 Hex oder ff. Das funzt doch nur bei TRUE mit dem Wert ff 
oder?

Wo kann man das nachlesen? Das ist doch Compiler spezifisch ob TRUE = 1 
ist oder eben nur ungleich NULL oder ALLES auf 1.
Das ist doch für die obige Abfrage essentiell...oder?

MfG
Achim

[Clown (Gast)]

Die höhere Priorität des Vergleichsoperators bewirkt, daß der Ausdruck 
derart ausgewertet wird, als ob der Teil

TCP_PORT_TABLE[port_index].port!=(htons(tcp->TCP_DestPort))

extra in Klammern stehen würde. Der ANSI C Standard besagt:

The && operator shall yield 1 if both of its operands compare
unequal to 0, otherwise it yields 0.  The result has type int.

und

Unlike the bitwise binary & operator, the && operator guarantees
left-to-right evaluation; there is a sequence point after the
evaluation of the first operand.  If the first operand compares equal
to 0, the second operand is not evaluated.

Der Vergleichsoperator liefert, ebenso wie auch die logischen 
Operatoren, einen Integer-Wert von 1 oder 0 zurück. Wenn nun bereits der 
erste Ausdruck des logischen UND Vergleichs gleich Null ist, wird der 
zweite Teil gar nicht mehr ausgewertet, da als Ergebnis nur Null 
herauskommen kann.

Es wird also zuerst ausgewertet, ob TCP_PORT_TABLE[port_index].port 
ungleich Null ist. Nur wenn das der Fall ist, wird 
TCP_PORT_TABLE[port_index].port mit (htons(tcp->TCP_DestPort)) 
verglichen. Und nur wenn sich die beiden Werte unterscheiden, kommt als 
Ergebnis des Vergleichs eine 1 heraus und ergibt logisch-und-verknüpft 
mit dem ersten Teil als Ergebnis die 1 für den Gesamtausdruck.

Die While-Schleife läuft demnach so lange, wie in der Tabelle an der 
Stelle [port_index] weder eine Null noch der gesuchte Wert steht.

[Sucher (Gast)]

Hallo @Clown,

herzlichen Dank für Deine ausführliche, mühevolle Erklärung!

Ich habe noch folgendes Denkproblem:

Annahme:

TCP_PORT_TABLE[port_index].port wäre = 2  und
htons(tcp->TCP_DestPort  wäre = 1

Also wird verglichen

  TCP_PORT_TABLE[port_index].port!=(htons(tcp->TCP_DestPort))

da beide ungleich sind kommt da ne 1 raus sagen wir vergleich=1

dann kommt mein Problem, jetzt wird das logische UND ausgewertet

TCP_PORT_TABLE[port_index].port && vergleich

und das gibt doch 0 (...000010 && ...000001)

und die Schleife wird verlassen. Wo liegt da mein (Denk)-Fehler?

Die Funktion der Schleife ist mir schon klar, aber wie beschrieben kann 
ich das nicht vollständig erklären. Die schleife sucht in einer Tabelle, 
die mit NULL abgeschlossen ist einen Port. Falls das Port gefunden wird 
zeigt der index auf den Port Eintrag. Falls nicht gefunden auf die NULL 
am Tabellenende.

Aber da erkenne ich noch nicht vollständig.


Kannst du mir da BITTE noch den Rest klären....

Vielen Dank
Achim

[Karl H. (kbuchegg)]

Sucher schrieb:

> dann kommt mein Problem, jetzt wird das logische UND ausgewertet
>
> TCP_PORT_TABLE[port_index].port && vergleich
>

das kommt drauf an welchen Wert TCP_PORT_TABLE[port_index].port hat.
Ist er 0 oder ist er nicht 0

> und das gibt doch 0 (...000010 && ...000001)

Ich denke du verwechselst jetzt gerade logisches Und (&&) mit binärem 
Und (&)

Denn bei einem && (logischem Und) ergibt 000010 && 000001 ein tadelloses 
TRUE. 000010 ist ungleich 0 und damit TRUE. 000001 ist ungleich 0 und 
damit TRUE. TRUE && TRUE ergibt TRUE.

Bei einem & (binärem Und) allerdings kommt da 0, also FALSE heraus. Aber 
das steht ja nicht dort. In deinem Code ist ein && und kein &.


Schreib deine Schleifenbedingung mal in Langform (die bedeutungsmässig 
100% äquivalent ist)

   while ( TCP_PORT_TABLE[port_index].port != 0    &&
           TCP_PORT_TABLE[port_index].port != htons(tcp->TCP_DestPort)
         )
     port_index++;

Jetzt klarer?
Einen Vergleich auf != 0 kannst du dir in solchen Fällen immer sparen. 
&& weiß schon, dass seine zu verknüpfenden Teilausdrücke mit boolscher 
Logik zu sehen sind und wertet alles was != 0 ist, automatisch als TRUE

[Sucher (Gast)]

Hallo

@Karl heinz Buchegger vielen Dank.

>Denn bei einem && (logischem Und) ergibt 000010 && 000001 ein tadelloses
>TRUE. 000010 ist ungleich 0 und damit TRUE. 000001 ist ungleich 0 und
>damit TRUE. TRUE && TRUE ergibt TRUE.

>Bei einem & (binärem Und) allerdings kommt da 0, also FALSE heraus. Aber
>das steht ja nicht dort. In deinem Code ist ein && und kein &.

ok. Das war mein Fehler. Das Problem sitzt an der Tastatur...

Der Code stammt nicht von mir, sondern ich möchte in nur verstehen.

@ALL Vielen Dank

MfG
Achim