Bug 794 – Ipv4Mask constructor for "/yy"-notation is wrong

Bug 794 - Ipv4Mask constructor for "/yy"-notation is wrong


Summary:	Ipv4Mask constructor for "/yy"-notation is wrong

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	network
Version:	pre-release
Hardware:	All All

Importance:	P2 normal
Assigned To:	Craig Dowell

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2010-01-20 03:23 UTC by Antti Mäkelä
Modified:	2010-02-05 13:04 UTC (History)
CC List:	3 users (show)

See Also:

Attachments
patch to fix (840 bytes, patch) 2010-01-21 23:02 UTC, Tom Henderson	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Antti Mäkelä 2010-01-20 03:23:30 UTC

In src/node/ipv4-address.cc, line 71 and onwards,

The constructor should be:

Ipv4Mask::Ipv4Mask (char const *mask)
{
  if (*mask == ASCII_SLASH)
    {
      uint32_t plen = static_cast<uint32_t> (atoi (++mask));
      NS_ASSERT (plen <= 32);
      m_mask = 0xffffffff >> (32-plen);
    }
  else
    {
      m_mask = AsciiToIpv4Host (mask);
    }
}

Right now it just places the prefix length, as is, to m_mask, ending up with some rather weird results.

Comment 1 Antti Mäkelä 2010-01-20 04:45:14 UTC

Whoops, obviously the bit-shift should be to other direction, so 

m_mask = 0xffffffff << (32-plen);

is correct.

Comment 2 Tom Henderson 2010-01-21 23:02:27 UTC

Created attachment 733 [details]
patch to fix

IMO, this is ready to commit.  Tested (does not change any existing test output).  I made a slight adjustment to what was previously posted for the boundary condition of "/0".

Comment 3 Craig Dowell 2010-01-22 02:01:14 UTC

+1 on readiness.

This is a P5 bug, so theoretically we should not commit until release unless the priority is bumped.

Comment 4 Josh Pelkey 2010-01-31 15:48:14 UTC

(In reply to comment #3)
> +1 on readiness.
> 
> This is a P5 bug, so theoretically we should not commit until release unless
> the priority is bumped.

Craig, can you push this one?

Comment 5 Craig Dowell 2010-02-05 13:04:08 UTC

changeset 8dcb272f3c00