Wozu htonl(3) UND ntohl(3)?

[Herakles]

Moin!

Um Daten zwischen zwei Rechner hin und her zu senden, kann man ja mehr-byte-ige Zahlen mittels htonl/htons in die Networkbyteorder konvertieren und umgekehrt mit ntohl/ntohs wieder zurückwandeln. Je nach Architektur sind diese Funktionen dann Dummys oder eben "echte" Byte-Dreher.

Nun habe ich soeben bemerkt, dass in der Implementation beide Funktionen dasselbe tun:

u32_t
htonl(u32_t n)
{
  return ((n & 0xff) << 24) |
  ((n & 0xff00) << 8) |
  ((n & 0xff0000UL) >> 8) |
  ((n & 0xff000000UL) >> 24);
}

u32_t
ntohl(u32_t n)
{
  return htonl(n);
}

So, jetzt erzählt mir mal, wieso gibt es denn wohl ZWEI Funktionen? Hat das einen historischen Grund? Oder hat da jemand zwei Funktionen verkaufen können und doppelt Geld kassiert? Wieso gibt es nicht einfach eine "convert_between_network_and_host(uint32_t)" bzw. "convert_between_network_and_host(uint16_t)"?

Ich bin gerade etwas verwirrt. Vielleicht sehe ich auch vor lauter Bäumen den Wald nicht...

Grüße
Herakles

 

[Yamagi]

Die sieht den Wald nicht. Du sitzt an einer x86-Maschine und hast daher die Kombination "Netzwerk == Big Endian ; Host == Little Endian". In diesem Fall hast du völlig recht, eine Funktion würde reichen. Aber du musst bedenken, dass es noch drei weitere Kombinationen geben kann. Wobei in der Praxis eigentlich nur noch "Netzwerk == Big Endian ; Host == Big Endian" relevant ist. Als Entwickler möchtest du, dass dein Code ohne Änderung in allen Kombinationen funktioniert. Daher zwei Funktionen, die je nach Host und Network Byte Order entsprechend implementiert sind und "magisch" das Richtige machen. Du schiebst stumpf alles aus dem Netzwerk zum Host durch ntohl() und alles vom Host zum Netzwerk durch htonl().

 

[Crest]

Es gab mal Hardware die mixed Endian verwendete.

Die hton* und ntoh* Funktionen sind Permutationen auf Ebene der Bytes. Es gibt/gab Plattformen auf denen diese Permutationen nicht selbstinvers sind.

 

[Herakles]

Danke, vor Allem an Crest!

Grüße