address-of-temporary idiom not allowed in C++

[pabigot]

Several places in Zephyr, particularly but not exclusively the Bluetooth stack, use an idiom of taking the address of a structure literal to pass complex configuration information into a function. Below is what is used to produce the BT_LE_ADV_CONN parameter passed to bt_le_adv_start() to identify the type of advertisement:

#define BT_LE_ADV_PARAM(_options, _int_min, _int_max) \
		(&(const struct bt_le_adv_param) { \
			.options = (_options), \
			.interval_min = (_int_min), \
			.interval_max = (_int_max), \
		 })
		 
#define BT_LE_ADV_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE, \
				       BT_GAP_ADV_FAST_INT_MIN_2, \
				       BT_GAP_ADV_FAST_INT_MAX_2)
...
bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), NULL, 0);

Taking the address of a temporary is an error when using C++: the correct idiom in that environment involves passing the temporary by reference. Allowing this idiom to be used requires -fpermissive, which is not a good solution.

[pabigot]

This is a serious bug to the degree C++ is supposed to be usable for Zephyr applications. A fix may require a different API for C++. The priority should be based on the desire for supporting C++ use.

[aescolar]

CC @jhedberg

[jhedberg]

I understand the problem, but I don't see how this is preventing C++ usage. C++ code could just declare a struct bt_le_adv_param stack variable and pass a reference to it to bt_le_adv_start() instead of using the BT_LE_ADV_PARAM() macro. I'm not aware of any place (at least in the Bluetooth code) that requires using these helpers.

[pabigot]

It doesn't prevent C++ usage, even with the same apparent application-level API that's used for C code, as in all the examples.

It does mean that the definition of those macros, and the signature of bt_le_adv_start(), would be different in C++. Which could be confusing.

The macros would have to expand to a temporary object, rather than the address of a temporary, and the globally visible bt_le_adv_start() would have to take a reference rather than a pointer.

[jhedberg]

@pabigot let me clarify: the BT_LE_ADV_PARAM() macro is an optional helper that was added after the fact to save some lines of code. It's perfectly fine for an application to do something like this:

struct bt_le_adv_param my_param = {
        ...
};

bt_le_adv_start(&my_param, ...);

[pabigot]

Agreed; the thing is that sample code uses that, and it's convenient for many cases, so it'd be nice if the same source worked in C++. That gets to the question of exactly what C++ support in Zephyr means. But it certainly can be done.

I do not think that the solution is to remove the use of this idiom from Zephyr, but possibly to add look-alike C++ API alternatives to the header.