Kniffligere Präprozessor-Direktive
Kniffligere Präprozessor-Direktive
Ich habe ein Konstrukt
if (0x0011!=ntohl(0x0011))
mit dem ich feststelle, ob auf einer Maschine ein Unterschied zwischen Net- und Host-Byteorder besteht. Das Ding hätte ich jetzt gerne als Präprozessordirektive.
#if (0x0011!=ntohl(0x0011))
funzt aber leider nicht. Geht sowas überhaupt mit einer "normalen" funktion wie ntohl()?
if (0x0011!=ntohl(0x0011))
mit dem ich feststelle, ob auf einer Maschine ein Unterschied zwischen Net- und Host-Byteorder besteht. Das Ding hätte ich jetzt gerne als Präprozessordirektive.
#if (0x0011!=ntohl(0x0011))
funzt aber leider nicht. Geht sowas überhaupt mit einer "normalen" funktion wie ntohl()?
Re: Kniffligere Präprozessor-Direktive
Nein.
Was spricht denn gegen if (0x0011!=ntohl(0x0011))?
c ya,
Tobias
Was spricht denn gegen if (0x0011!=ntohl(0x0011))?
c ya,
Tobias
dude i'm pretty damn sure you could script somebody back to life
Re: Kniffligere Präprozessor-Direktive
#define BANANE (0x0011!=ntohl(0x0011))
...
if ( BANANE ) {
}
...
if ( BANANE ) {
}
Re: Kniffligere Präprozessor-Direktive
Die Geschichte mit dem #if funzt schlichtweg nicht, der Compiler (bzw. Präprozessor) weigert sich, das zu akzeptieren.
Tja und
#define BANANE (0x0011!=ntohl(0x0011))
if ( BANANE ) {
hat den Nachteil, dass das nach dem Präprozessor doch wieder nur aktiver Code der Sorte
if (0x0011!=ntohl(0x0011))
ist. Ich suche aber nach einer Möglichkeit, die den Code nur auf Maschinen drinlässt, deren Host-Byteorder != der Network-Byteorder ist und ansonsten den Teil innerhalb der #if-Bedingung schlichtweg weglässt.
Tja und
#define BANANE (0x0011!=ntohl(0x0011))
if ( BANANE ) {
hat den Nachteil, dass das nach dem Präprozessor doch wieder nur aktiver Code der Sorte
if (0x0011!=ntohl(0x0011))
ist. Ich suche aber nach einer Möglichkeit, die den Code nur auf Maschinen drinlässt, deren Host-Byteorder != der Network-Byteorder ist und ansonsten den Teil innerhalb der #if-Bedingung schlichtweg weglässt.
Re: Kniffligere Präprozessor-Direktive
Verstehe ich dich richtig?
Der Präprozessor soll rausfinden ob ein Unterschied zwischen der Net- und Hostbyteorder besteht?
Und zwar indem er den Ausdruck (0x0011!=ntohl(0x0011)) auswertet, wobei ntohl eine Funktion der C-Lib ist?
Das funktioniert so auf keinen Fall!
Vielleicht liefer der gcc ja Konstanten auf welcher Architektur er grade läuft, ansonsten musst du dir diese selber definieren, und beim Kompilieren entsprechen setzen.
in etwa
#ifdef ( I386 )
#elseif ( SPARC )
#elseif ( MIPS )
#else
#endif
Der Präprozessor soll rausfinden ob ein Unterschied zwischen der Net- und Hostbyteorder besteht?
Und zwar indem er den Ausdruck (0x0011!=ntohl(0x0011)) auswertet, wobei ntohl eine Funktion der C-Lib ist?
Das funktioniert so auf keinen Fall!
Vielleicht liefer der gcc ja Konstanten auf welcher Architektur er grade läuft, ansonsten musst du dir diese selber definieren, und beim Kompilieren entsprechen setzen.
in etwa
#ifdef ( I386 )
#elseif ( SPARC )
#elseif ( MIPS )
#else
#endif
Re: Kniffligere Präprozessor-Direktive
Hi,
es gibt irgendwo ein Macro für die Byte-Order, ich weiß allerdings nicht, ob es Linux-spzifisch ist. Enfach mal grep ENDIAN in allen Includes...
Gruß,
hjb
es gibt irgendwo ein Macro für die Byte-Order, ich weiß allerdings nicht, ob es Linux-spzifisch ist. Enfach mal grep ENDIAN in allen Includes...
Gruß,
hjb
Pro-Linux - warum durch Fenster steigen, wenn es eine Tür gibt?
Re: Kniffligere Präprozessor-Direktive
Ok, dann frag' ich mal anders <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Welche Byteorder ist im Netz denn üblich - das Gleiche, was Motorola-Prozessoren auch machen, also von High-Byte nach Low-Byte (richtig rum also <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> ?
Und wie sieht die Byteorder auf einem Sparc-Prozessor aus? Mehr als ix86, PPC und Sparc will ich eh' nicht abdecken...
Welche Byteorder ist im Netz denn üblich - das Gleiche, was Motorola-Prozessoren auch machen, also von High-Byte nach Low-Byte (richtig rum also <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> ?
Und wie sieht die Byteorder auf einem Sparc-Prozessor aus? Mehr als ix86, PPC und Sparc will ich eh' nicht abdecken...
Re: Kniffligere Präprozessor-Direktive
Hi!
Habe mal eben im IRC einen Sparc-Assemblerprogrammierer gefragt:
<wolfgang> is sparc correct-endian?
<inituni> wolfgang : no
Cheers,
GNU/Wolfgang
Habe mal eben im IRC einen Sparc-Assemblerprogrammierer gefragt:
<wolfgang> is sparc correct-endian?
<inituni> wolfgang : no
Cheers,
GNU/Wolfgang
Re: Kniffligere Präprozessor-Direktive
Tach Zusammen
Hat ein normaler PC-CPU die Netzwerk Byteorder oder gibt es da noch Unterschiede zwischen AMD und Intel?
Habe über localhost auf einen Server mit Telnet zugegeriffen, der den Port nicht mit htns(PORT) definiert hatte, und es ging nicht. Es funktionierte erst, als ich htns() benutzte.
Ach ja, ich habe einen Athlon.
Kennt jemand den Grund?
thx
user1
Hat ein normaler PC-CPU die Netzwerk Byteorder oder gibt es da noch Unterschiede zwischen AMD und Intel?
Habe über localhost auf einen Server mit Telnet zugegeriffen, der den Port nicht mit htns(PORT) definiert hatte, und es ging nicht. Es funktionierte erst, als ich htns() benutzte.
Ach ja, ich habe einen Athlon.
Kennt jemand den Grund?
thx
user1
Re: Kniffligere Präprozessor-Direktive
So, was ich inzwischen rausbekommen habe:
Network-Byteorder = Motorola = "richtig rum", also HighByte/LowByte
Alle Intel- (und AMD-) Prozessoren haben keine Network-Byteorder, sondern sind "falschrum" (gerade anders herum, wie Zahlen schriftlich auch dargestellt werden), also LowByte/HighByte
Tja und Sparc? Keine Ahnung...
Network-Byteorder = Motorola = "richtig rum", also HighByte/LowByte
Alle Intel- (und AMD-) Prozessoren haben keine Network-Byteorder, sondern sind "falschrum" (gerade anders herum, wie Zahlen schriftlich auch dargestellt werden), also LowByte/HighByte
Tja und Sparc? Keine Ahnung...
Re: Kniffligere Präprozessor-Direktive
Tach
thx
Aber wieso hat der PC little endian? Ist doch falsch <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">
Im Dezimalen kommt ja auch die hochwertigste Zahl zuerst.
Gruss user1
thx
Aber wieso hat der PC little endian? Ist doch falsch <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">
Im Dezimalen kommt ja auch die hochwertigste Zahl zuerst.
Gruss user1
Re: Kniffligere Präprozessor-Direktive
Klar ist das falsch - aber sag' bzw. frag das Intel, die haben sich den Mist einfallen lassen! Naja, von denen stammen ja noch andere dämliche Ideen wie z.B. die Geschichte mit den nicht beliebig benutzbaren Prozessorregistern, die außer den Chipdesignern wahrscheinlich kein Mensch wirklich verstanden hat.
Btw: Ich weiß nicht mehr genau, ob das beim Alpha so ist, aber es gibt noch schrägere Zahlendarstellungen. Wenn Motorola z.B. eine 32-Bit-Zahl als AABBCCDD und Intel als DDCCBBAA darstellt, macht dieser (Alpha?) da BBAABBCC draus *graus*
Btw: Ich weiß nicht mehr genau, ob das beim Alpha so ist, aber es gibt noch schrägere Zahlendarstellungen. Wenn Motorola z.B. eine 32-Bit-Zahl als AABBCCDD und Intel als DDCCBBAA darstellt, macht dieser (Alpha?) da BBAABBCC draus *graus*
Re: Kniffligere Präprozessor-Direktive
Bei einem 16 Bit Prozessor könnte ich mir das noch vorstellen, aber bei einem 64 Bit Alpha...
Re: Kniffligere Präprozessor-Direktive
OK, es hat sich geklärt, Sparcs sind genau so falsch rum wie die Intel-Dinger: http://www.support.compaq.com/amt/freep ... ndian.html
Re: Kniffligere Präprozessor-Direktive
Hallo!
Auch wenn es auf den ersten Blick falschherum erscheint, little-endian hat einige signifikante Vorteile. Zum Beispiel beim Vergroessern von Speicherbereichen (relloc()).
Soweit ich weiss, sind die meisten Netzwerkprotokolle big-endian. Er bedarf allerdings nur einer kleinen Funktion, um die "byteorder" auf einer little-endian Masschine entsprechend zu aendern.
PPC ist uebrigens bi-endian.
Gruss,
Gregor
Auch wenn es auf den ersten Blick falschherum erscheint, little-endian hat einige signifikante Vorteile. Zum Beispiel beim Vergroessern von Speicherbereichen (relloc()).
Soweit ich weiss, sind die meisten Netzwerkprotokolle big-endian. Er bedarf allerdings nur einer kleinen Funktion, um die "byteorder" auf einer little-endian Masschine entsprechend zu aendern.
PPC ist uebrigens bi-endian.
Gruss,
Gregor