sd_ble_gatts_hvx struct is passed as const, yet ble_gatts_hvx_params_t::p_len is modified

[natersoz]

It appears to be an error in the function signature `sd_ble_gatts_hvx()`.

Since the call is made via software interrupt, the const qualifier is cast away regardless.

So, most likely this is just a form of documentation error?

Please confirm, thanks.

[Håkon Alseth]

Hi,

Interesting topic.

Provided that the object pointed to does not change memory location, the compiler will accept this. Although, still a bit confusing with the const qualifier for struct pointers in C.

Here's an example.

OK: *p_hvx_params->p_len = 0;
Not OK: p_hvx_params->p_len = 0;

Best regards,

Håkon

[natersoz]

For example (code snippet):

uint16_t const length = 4u;
hvx_params.p_len = &length;
uint32_t error_code = sd_ble_gatts_hvx(&hvx_params);

*hvx_params.p_len = ??

The comments say that p_len's pointed to value may by changed by the call (perhaps the buffer did not allow for enough space?) . But p_len is a const pointer.

Looking for clarification here: Will the returned value of p_len be different than the value passed in? Ever?

[Håkon Alseth]

*p_len value can be altered by the softdevice, as per the API documentation:

 @param[in,out] p_hvx_params Pointer to an HVx parameters structure. If @ref ble_gatts_hvx_params_t::p_data
 *                             contains a non-NULL pointer the attribute value will be updated with the contents
 *                             pointed by it before sending the notification or indication. If the attribute value
 *                             is updated, @ref ble_gatts_hvx_params_t::p_len is updated by the SoftDevice to
 *                             contain the number of actual bytes written, else it will be set to 0.

You can therefore set the value by de-referencing "*p_hvx_params->p_len=1234;", but not change the actual RAM location it points to.

Best regards,

Håkon