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