[QUESTION] binary_t out parameter

[djmuhlestein]

If you didn't find answer in existing open/closed issues you may ask here

I tried to make an interface with a binary_t out parameter. Example:

interface TestInterface {
   get_data(out binary_t data) -> void
}

The resulting shim code creates a binary_t *data = NULL but then passes that to the interface function.

e.g: m_handler->get_data(data)

It is then impossible in your interface handler to return the data. You can't set *data because the ptr wasn't passed in as a double ptr. Nor can you assign anything to data because it's NULL.

Question is whether or not this is a feature request to be able to support out parameter binary_t or if this is a bug and should be fixed?

As a workaround, I am changing it to an inout parameter.

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/closed PR which is solving this issue.
• [ x] I looked in documentation if there is related information.

[amgross]

HI @djmuhlestein
Thanks for your interest.
First of all, your example is bit weird because erpcgen is expect binary and not binary_t (like it expect int32 and not int32_t) so maybe your issue is there.
I tested:

interface TestInterface {
   get_data(out binary data) -> void
}

The output code I got allocating memory into data (indeed after initializing with NULL, but it makes no difference).

in [name]_server.cpp:

    binary_t *data = NULL;

    // startReadMessage() was already called before this shim was invoked.

    data = (binary_t *) erpc_malloc(sizeof(binary_t));
.
.
.
     m_handler->get_data(data);

[djmuhlestein]

Hi, @amgross thank you for the reply.

Yes you are correct the following is right, I used binary_t because I was looking at the cpp generatred code.

interface TestInterface {
   get_data(out binary data) -> void
}

The output code I got allocating memory into data (indeed after initializing with NULL, but it makes no difference).

in [name]_server.cpp:

    binary_t *data = NULL;

    // startReadMessage() was already called before this shim was invoked.

    data = (binary_t *) erpc_malloc(sizeof(binary_t));
.

Sorry, I missed that allocation when I was first looking through things. It's a bit difficult to debug on my platform since my erpc code is running on an embedded processor. But yes, the allocation is there for me as well.

I think I mistook the actual problem due to the following lines:

if (data)
    {
        free_binary_t_struct(data);
    }
erpc_free(data);

The original erpc_malloc gives us a data struct but not data->data. So it appears the client is reponsible for allocating the actual data buffer. free_binary_t_struct will check for data->data and call erpc_free on it. So it looks like the only possible way to use this data paramater is to allocate it with erpc_malloc in your handler function. I think that was the source of my crashes originally. I had tried to assign data->data to a static buffer.

It's unclear from documentation how this should actually be handled.

[amgross]

Hi @djmuhlestein , thank you for the clarification.
In our explanation about allocation we state that allocation and free is done in server SHIM. What is missing there is that in case of out structs the inner buffers allocation is not done.

solution for your use case
You will need to create your own binary struct and define the internal parameter as retained (not to be free), It is important to note you shouldn't just add to your original .erpc file the retain annotation on the binary data as then also the struct itself won't get free.
Your fixed erpc file should look like:

struct retainedBynary_t
{
  uint32 dataLength;
  binary data @length(dataLength);
}

interface TestInterface {
   get_data(out retainedBynary_t data) -> void
}

Please let me know if this solution is good for you.

[djmuhlestein]

@amgross, yes, that can be a solution for using a static buffer. Also it seems if a dynamic buffer is desired, simply using erpc_malloc to create it is sufficient. Maybe a NOTE in the IDL reference containing this detail would suffice.

[amgross]

Hi @djmuhlestein ,
Unfortunately I am not maintainer of this repo, I suggest you will write here the way you think it should be written and link @MichalPrincNXP to it