Endian bug in KNetwork::KIpAddress
Nadeem Hasan
nhasan at nadmm.com
Fri Jul 21 21:13:25 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I think I just found an endian bug in KIpAddress. Look at the following:
inline bool isClassD() const
{ return version() != 4 ? false : (IPv4Addr() & 0xf0000000) == 0xe0000000; }
and
inline Q_UINT32 IPv4Addr(bool convertMapped = true) const
{
return (convertMapped && isV4Mapped()) ? m_data[3] : m_data[0];
}
and
if (inet_pton(AF_INET, address.latin1(), &buf))
{
*m_data = buf;
m_version = 4;
return true;
}
Now...
KNetwork::KIpAddress ip( "224.5.6.7" );
if ( ip.isClassD() ) // returns false instead of true
{
// blah
}
You spot the problem? IPv4Addr() retruns in_addr_t returned by inet_pton()
in network byte order (big endian). The code is accessing that as little
endian, and fails this test for class D addresses. Other methods like
isClassC() etc. also suffer from the same bug.
I am really surprised that this was not caught so far. Makes me doubt
myself actually, but it really does not work according to my tests. So I
am fairly sure this is not a false alarm.
There are 2 ways to fix this...
1. Store the address in host order.
2. Call ntohl() everytime for the address.
I am not set up right now to easily fix this myself. Thiago, could you
please take a look?
Regards.
- --
Nadeem Hasan (nhasan-at-nadmm.com)
GPG Fingerprint: 7141 0B1C 9CAF 624D 307F F8EF 6C0C 753E DD3A 0F53
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFEwTVlbAx1Pt06D1MRAmpuAJ9wryFKXYHI4UGZnhWtE612iCyb4QCfb5Tl
4+XTLCgiyOX7omiVIxiwIZg=
=WnNd
-----END PGP SIGNATURE-----
More information about the kde-core-devel
mailing list