Why does the Fw::Buffer constructor take a non-const data pointer?

[epdalessandro]

From my understanding of Fw::Buffer it should be copying the data from the source so taking a const-pointer would make sense, it takes a size parameter that would allow you to do this well.

Not doing this means that if that if you want to convert a string to an Fw::Buffer object you are required to use strcpy() or strncpy() which are both memory-unsafe methods.

Right now the constructor appears to just point to the data array as well. I'm also not really sure how it ensures that the data array being pointed to is valid after construction (maybe in this line this->m_serialize_repr.setExtBuffer(this->m_bufferData, this->m_size); but I'm not sure where that function is defined)

[LeStarch]

Fw::Buffer wraps a pointer, but does not perform a copy.

Thus, if you pass a pointer to the constructor it will store that pointer along with the size and shuttle it through the system .

[epdalessandro]

So can you ever return an Fw::Buffer object? If you declare the character array in a function, then construct a Fw::Buffer from it and then return it, shouldn't that be the same as returning a pointer to a local variable? Fw::Buffer doesn't own that memory, the local char* that was declared did (and is on the stack unless you allocate heap memory which I believe in flight software is frowned upon) and then destroyed on function exit invalidating the returned Fw::Buffer pointer

[timcanham]

Since Fw::Buffer is a container for a pointer, it is up to the user to understand the lifetime and usage of the pointer. You are correct that you can return a Fw::Buffer pointing to stack variable that will become invalid in the same way you could return a normal pointer from a function. The primary pattern for Fw::Buffer is for the memory to be managed and assigned by something like Svc/BufferManager and passed around the system for usage before returning it to BufferManager when complete. The knowledge of the ownership of the memory is designed into the system by the designer, so if they make a programming error like pointing at a stack variable Fw::Buffer won't catch it. It's part of the trade between a completely bullet-proof design (where the memory travels with the buffer) and performance. The assumption is that a reasonably experienced programmer interacting with the documentation would avoid those kinds of errors.

[epdalessandro]

That makes sense, thanks for explaining the rationale behind the design decision!