[SOLVED its no bug!] Bug? IpAddress addr(1, 2, 3, 4); on big endian machine?

[jwurzer]

Hi!

I think I found a bug but I can't really test the bug because I have currently no big endian architecture (like PowerPC).

Bug is in the Constructor of IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3) at
SFML/src/SFML/Network/IpAddress.cpp

Current Version of IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3):

IpAddress::IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3) :
m_address(htonl((byte0 << 24) | (byte1 << 16) | (byte2 << 8) | byte3)),
m_valid  (true)
{
}

I think it should be without the htonl and shift the bytes directly for the big endian format.

IpAddress::IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3) :
m_address((byte0 << 0) | (byte1 << 8) | (byte2 << 16) | (byte3 << 24)),
m_valid  (true)
{
}

IpAddress x(1, 2, 3, 4);
x.toString(); // will currently prodoce "4.3.2.1" on big endian machine?

I think this would currently produce "4.3.2.1" on big endian machine. Or otherwise I have an error in reasoning 

[FRex]

I don't think so. The function used to convert to string is inet_ntoa and it uses the network order (as does the field in IpAddress).

https://github.com/SFML/SFML/blob/master/src/SFML/Network/IpAddress.cpp#L92

https://linux.die.net/man/3/inet_ntoa

[jwurzer]

I have an error in reasoning :-D The current git-code is correct! (NO bug)

example:
little endian:

IpAddress(1, 2, 3, 4);
-->
(1 << 24) | ( 2 << 16) | (3 << 8) | (4 << 0) = 0x01020304
-->
0x01020304 (host order, little endian, in memory: 0x04, 0x03, 0x02, 0x01)
--> htonl(0x01020304) --> 0x04030201 (network order, in memory: 0x01, 0x02, 0x03, 0x04)
0x04030201 (memory: 0x01, 0x02, 0x03, 0x04) in m_address is network order and is CORRECT!!!

example:
big endian architecture (host order = network order. htonl() return the same value)

IpAddress(1, 2, 3, 4);
-->
(1 << 24) | ( 2 << 16) | (3 << 8) | (4 << 0) = 0x01020304
-->
0x01020304 (host order, big endian, in memory: 0x01, 0x02, 0x03, 0x04)
--> htonl(0x01020304) --> 0x01020304 (network order, in memory: 0x01, 0x02, 0x03, 0x04)
0x01020304 (memory: 0x01, 0x02, 0x03, 0x04) is network order and the value (i think) is CORRECT.

Ok both examples have in memory 0x01, 0x02, 0x03, 0x04. So the code should have no bug :-D sorry ;-)