net/gipv4: Ip2long is inconsistent with inet_addr in cpp

[berstpander]

Go version

go version go1.21.9 linux/amd64

GoFrame version

v2.7.4

Can this bug be reproduced with the latest release?

Option Yes

What did you do?

I use Ip2long to convert IP address from string to uint.

What did you see happen?

example: 122.168.1.1
Ip2long("192.168.1.1") = 3232235777
inet_addr("192.168.1.1") = 16885952

What did you expect to see?

I hope they are consistent

[berstpander]

I went to see the implementation of the net.parseIP method in GO. In the parseIP, the order of the IP addresses after parsing has been reversed, the []byte returned has been reversed. So if use BidEndian.Uint32 is inconsistent with inet_addr in cpp。But I don't know if this is a bug or if the author deliberately handled it this way.

[oldme-git]

@berstpander The issue is not bug, 3232235777 is BigEndian result, 16885952 is LittleEndian result.

[gqcn]

@berstpander @oldme-git
IP addresses are typically converted to integers using Big-Endian byte order for the following reasons:

1. Network Byte Order Standard

• TCP/IP protocols specify that network transmission uses big-endian
• This was established because early computers used big-endian
• Therefore, IP addresses storage and transmission follow big-endian

2. Readability

• IP addresses are written left to right (e.g., 192.168.1.1)
• Big-endian stores high-order bytes first, matching IP address writing order
• Makes it easier for humans to understand and debug

Advantages of using Big-Endian:

1. Complies with network protocol standards
2. Matches IP address written format
3. Easier to debug and understand
4. Better cross-platform compatibility

In Go standard library:

• The net package uses big-endian for IP address handling
• encoding/binary package provides BigEndian for big-endian operations
• Network-related system calls use big-endian

Therefore, it's recommended to use big-endian when converting IP addresses to integers because:

1. Maintains consistency with network protocols
2. Improves code maintainability
3. Avoids byte-order compatibility issues

[gqcn]

@berstpander @oldme-git

Key Points:

1. inet_addr() in CPP DOES return in network byte order (big-endian)
2. The confusion comes from:
   • Viewing memory directly on little-endian machines
   • Not accounting for system byte order when printing
3. Network protocols always use big-endian (network byte order)
4. The C standard library provides conversion functions (htonl, ntohl) to handle byte order differences

Best Practices:

1. Always treat network addresses as big-endian
2. Use appropriate conversion functions when necessary
3. Be aware of system byte order when debugging
4. Remember: Network order (big-endian) ≠ Host order (system dependent)

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@gqcn

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@gqcn

[berstpander]

@gqcn
I understand what you said, But I still have some confusion.
The situation is this:

• First of all, I know that the output results of inet_addr() in CPP and Ip2long() in go are all big-endian.
• Then, I use two clients, client_01 using inet_addr() and other using Ip2long(). They encode the IP address into a 32-bit integer and send it to a server GO.These three programs are on the same computer and use little endian order.
• However, the numbers from the client displayed one in big endian order and other in little endian order on the server, which confuses me.