Bugzilla – Bug 139
Packet::RemoveTag is misleading
Last modified: 2008-07-01 13:32:23 UTC
Yes, I am frustrated because Packet::RemoveTag has deceived me and made me waste a lot of time. I had some code that used to do pkt->PeekTag (tag). It turns out I discovered a case where a packet was being re-routed and the same tag was being re-added. So I logically decided to switch to pkt->RemoveTag (tag). After an hour wasted (it was not obvious) in debugging it turned out this was a bad move. Packet::RemoveTag (tag) does not actually copy the tag! 1. Why does Packet::RemoveHeader (header) remove and return the header, but Packet::RemoveTag (tag) only removes the tag; this is very inconsistent... 2. If Packet::RemoveTag only removes the tag, and not return it, why does it take the 'tag' parameter at all? This is highly misleading... It should instead be Packet::RemoveTag<TAG_TYPE> ().
Re-titling the bug, after cooling down my frustration :P
(In reply to comment #0) > Yes, I am frustrated because Packet::RemoveTag has deceived me and made me > waste a lot of time. > > I had some code that used to do pkt->PeekTag (tag). It turns out I discovered > a case where a packet was being re-routed and the same tag was being re-added. > So I logically decided to switch to pkt->RemoveTag (tag). > > After an hour wasted (it was not obvious) in debugging it turned out this was a > bad move. Packet::RemoveTag (tag) does not actually copy the tag! sounds like a bug since the documentation clearly says it should. > > 1. Why does Packet::RemoveHeader (header) remove and return the header, but > Packet::RemoveTag (tag) only removes the tag; this is very inconsistent... Patch to align RemoveTag with RemoveHeader would be welcome. Another option would be, of course, to update the RemoveTag documentation to align it with its current implementation. Either way would be fine with me.
-> http://code.nsnam.org/ns-3-dev/rev/9df551386a93