[BUG] Warning about definition of implicit copy constructor

[PhilippHaefele]

Describe the bug

Currently the code uses implicit generation of the copy constructors in some places. Since C++11 this is declared as deprecated and therefore trows warnings.

In my build I do see the warning at erpc_c/infra/erpc_message_buffer.hpp Line 57, but there might be more places.

To Reproduce

compile sources with -Wall -Wextra or -Wdeprecated-copy in GCC (we use gcc-arm-none-eabi-10.3-2021.10)

Expected behavior

No -Wdeprecated-copy warning are in build output

Desktop

• OS: Build machine is Windows / WSL (GCC cross-compiled compiled for own eRPC uC/OS-II port, but shouldn't matter at all for this issue)
• eRPC Version: 1.12.0

Steps you didn't forgot to do

• [x] I checked if there is no related issue opened/closed.
• [x] I checked that there doesn't exist opened PR which is solving this issue.

Additional context

If I'm right it should be enough to add = default to the corresponding copy-constructors (available since C++11).

In VS Code i did use following regex to search for copy constructors (?<=\s|^)(\w+)(\(.*\1.*&.+\)) and there seems to be only the above mentioned one in the C/C++ integration code, that is not there to "delete" / hide the copy constructor (they could also be deleted with a = delete).

Not 100% sure if this change is feasible and results in the expected behavior.

Update: Should be fairly simply to fix by adding (not 100% sure, as I'm not a C++ expert):

MessageBuffer &operator=(const MessageBuffer &buffer);

MessageBuffer &erpc::MessageBuffer::operator=(const MessageBuffer &buffer)
{
    m_buf = buffer.m_buf;
    m_len = buffer.m_len;
    m_used = buffer.m_used;

    return *this;
}

[github-actions[bot]]

Hi eRPC user. Thank you for your interest and welcome. We hope you will enjoy this framework well.

[PhilippHaefele]

@Hadatko @MichalPrincNXP Any thoughts on this and/or should I create a PR for this?

[PhilippHaefele]

When changing API to suggested one in https://github.com/EmbeddedRPC/erpc/issues/416 it's maybe not needed anymore

@MichalPrincNXP @Hadatko Any thoughts on one of the two issues (this on and #416) ?