Confusing definition

[michurin]

C:\Nordic Semiconductor\nrf51_sdk_v4_4_1_31827\nrf51822\Include\ble\softdevice\ble_gatts.h

typedef struct {
  uint16_t     handle;    /**< Attribute Handle. */
  uint8_t       op;          /**< Type of write operation, see @ref BLE_GATTS_OPS. */
  ble_gatts_attr_context_t    context;     /**< Attribute Context. */
  uint16_t      offset;      /**< Offset for the write operation. */
  uint16_t      len;          /**< Length of the incoming data. */
  uint8_t       data[1];    /**< Incoming data, variable length. */
} ble_gatts_evt_write_t;

My question is how to interpret the element data[1]? Is it just uint8_t *data(C-wise it is)? If so why is it defined in such a way? Especially with the size of the data array as one with the following comment about its variable length which all together makes this definition very confusing.

Thanks.

[Ole Morten]

The point of this declaration is that the array is actually located here, and it's not just a pointer to another area. In C99, you would write this as data[], but this is not legal in C89, hence this [1].

Having it like this

struct
{
    uint8_t * data;
} ble_gatts_evt_write_t;

would imply there is just a pointer to some other memory area in the actual event structure, while this

struct
{
    uint8_t data[]; // or data[1] in C89
} ble_gatts_evt_write_t;

shows that the entire data is actually located in this memory area.

Initially, it was a requirement for the softdevice headers to be C89 compliant, and even though we've abandoned this, some things like this still lingers in the code. However, when using this buffer, these two declarations are mostly equivalent, although it may matter in case you need to copy the structure.

It seems to me that this blog post explains the difference between a pointer and an array in a good way, if the difference is still unclear.

[michurin]

Sorry Ole, I'm not satisfied. some_t data[X] allocates memory for X elements of some_t, in our case uint8_t data[1] allocates exactly one byte. Yet the comment says variable length! Is this not confusing? One needs to choose array of predefine length of exact or max_len size or void pointer which application will cast to the necessary type. Once again I'm finding existing typedef including its comment confusing: If one has more then one write event and they do have different length of writing data then more then one typedef will be required.

[michurin]

One more thing: if array has predefined length then it needs to be less than uint16_t len; /* Length of the incoming data. */.

The way I see the intention of the developer is:

typedef union {
unit8_t event_x[1];  /* event x message */
uint16_t event_y[2];/* event y message */
void *event_z; /* event z message */
/* more event messages if necessary */
} event_message_t; /* union will have the size of known largest message */
struct
{
...
uint16_t len; /* Length of the incoming data; len <= sizeof(event_message_t); */
event_message_t data;
}ble_gatts_evt_write_t;

[Ole Morten]

I'm sorry, but I can't really help that you find it confusing, but this is perfectly valid C, and the use case is fine: to make it clear that the array is placed inside the struct, and not just a pointer to somewhere else.

I'd again like to recommend having a look at the blog post I linked. Also remember that this struct is inside a ble_evt_t, and where it is primarily used, in BLE_STACK_HANDLER_INIT(), space is allocated like this: static uint32_t EVT_BUFFER[CEIL_DIV(sizeof(ble_evt_t) + (MTU_SIZE), sizeof(uint32_t))]; This makes sure that sufficient space will actually be allocated, since the MTU_SIZE is added to the sizeof(ble_evt_t), exactly to accommodate the variable size arrays that are part of several events.

[Ole Morten]

This isn't really feasible, as the value within this array can be any data, of any format. If you look into the on-air operations, there is no requirement that this data is structured in any way. Also, even if the characteristic value have a certain structure, the data used here can be offset, and hence have no structure after all. A variable sized array is therefore the only reasonable option as far as I can see.