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]

"in my opinion whether that's any clearer is mostly a matter of taste, when most of this array may very well be uninitialized memory." I'm always applying the rule: clearly define the object and use it's definition. In other words in my application expects a message it needs to know how to interpret it. So typedef enum { MON, TUE, WED, THU, FRI, SAT, SUN } my_app_t is much better than uint8_t week_day; And when the message structure is typedef struct { my_app_t begin; my_app_t end; } my_msg_t; I'd verify that len is == sizeof(my_msg_t) and then will use it as data->begin and data->end and not data[0] and data[1] and getting warning about data[1]... BTW Warnings should be strictly prohibited - compiler doesn't understand your intent and therefore such code is not portable even if it is correct for particular case.

Isn't if clear and very readable?!

uint8_t