OMNeT++/OMNEST Bug Tracker - OMNeT++ | |||||
| View Issue Details | |||||
| 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. | ||||
| Steps To Reproduce | |||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2017-05-24 20:29 | paolinux | New Issue | |||
| There are no notes attached to this issue. |