Anonymous | Login | 2019-02-17 08:49 UTC | ![]() |
My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0001013 | OMNeT++ | simulation kernel | public | 2017-05-24 20:29 | 2017-05-24 20:29 | ||||||||
Reporter | paolinux | ||||||||||||
Assigned To | |||||||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||||||
Status | new | Resolution | open | ||||||||||
Platform | x86_64 | OS | Windows | OS Version | 10 | ||||||||
Product Version | 5.1 | ||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0001013: The "controlInfo" field is not copied by the message copy constructor | ||||||||||||
Description | I've noticed that the controlInfo pointer associated to a given message is not copied by the copy constructor, i.e., the resulting copy will have controlInfo set to nullptr. I'm not sure if this actually a bug or is the intended behavior. However, this turns out to incur a non-expected behavior in the controlInfo are associated to an encapsulated packet. Consider the following example; auto encapsulatedMsg = new cMessage(); encapsulatedMsg.setControlInfo(...); auto msg = new cMessage(); msg->encapsulate(encapsulatedMsg); if now I call msg->getEncapsulatedPacket(); this creates a copy of the object that does not have the controlInfo. Wouldn't it make more sense to copy the controlInfo pointer to? (ie both the original message and the copy would point to the same memory location) P. | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files | |||||||||||||
![]() |
|||
Date Modified | Username | Field | Change |
2017-05-24 20:29 | paolinux | New Issue |
Copyright © 2000 - 2019 MantisBT Team |