Bug 686

Summary: Reading and Writing from zero areas - unexpected result
Product: ns-3 Reporter: Florian Schmidt <Florian.Schmidt>
Component: coreAssignee: ns-bugs <ns-bugs>
Status: RESOLVED INVALID    
Severity: minor CC: mathieu.lacage
Priority: P4    
Version: ns-3-dev   
Hardware: All   
OS: All   

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