Bug 686 - Reading and Writing from zero areas - unexpected result
Reading and Writing from zero areas - unexpected result
Status: RESOLVED INVALID
Product: ns-3
Classification: Unclassified
Component: core
ns-3-dev
All All
: P4 minor
Assigned To: ns-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-21 10:54 UTC by Florian Schmidt
Modified: 2009-11-25 07:46 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Schmidt 2009-09-21 10:54:31 UTC
Recently, I have started experimenting with error models in ns-3. I implemented a small model that actually inserts errors into the data. That is, it reads the packet buffer, changes the contents with a certain probability, and writes them back. For this, I have been using Packet::Begin() to get an iterator to the beginning of the packet, Buffer::Iterator::isEnd() to test when I am done, and Buffer::Iterator::ReadU8() and Buffer::Iterator::WriteU8() to read and write the data.

My problem is that, if I use one of the standard applications that only sends zeroes, the buffer contains a zero area. Reading bytes out of that zero area works fine: ReadU8() returns 0. However, if I try to write a byte into that area, I get an assertion error. I am not sure whether this is the correct behavior, and if it is, how to make it accept changed payloads. I cannot check whether I will write into a zero area with isEnd(), or the various GetSize() functions (Packet::, Buffer::, Buffer::Iterator::), because they all return the size of the packet with the zero area treated as the corresponding number of bytes. I also don't see any functionality that would allow me to make the Buffer expand its zero area to actual zeroes.

I am wondering: Have I found a bug in the buffer implementation? If not, is the described behavior considered suboptimal or even faulty? If not, is there a way to switch off the zero area optimization, so I get it to do what I want it to do?
Comment 1 Mathieu Lacage 2009-11-23 09:44:18 UTC
see also http://mailman.isi.edu/pipermail/ns-developers/2009-November/007038.html

I think that I am going to mark this as WONTFIX.
Comment 2 Mathieu Lacage 2009-11-25 07:46:54 UTC
INVALID since this is the way the API is expected to work