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

pabigot · 2019-08-21T15:51:41Z

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.

The text was updated successfully, but these errors were encountered:

pabigot · 2019-08-21T15:53:02Z

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 · 2019-08-22T06:52:44Z

CC @jhedberg

jhedberg · 2019-08-22T07:06:28Z

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 · 2019-08-22T11:34:28Z

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 · 2019-08-27T17:57:53Z

@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 · 2019-08-27T18:02:15Z

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.

maksimmasalski · 2019-09-29T05:49:04Z

@jhedberg
Hi, I was assigned to solve that issue. Can you give me please your vision of it?

jhedberg · 2019-09-29T07:45:47Z

I was assigned to solve that issue. Can you give me please your vision of it?

@maksimmasalski I'm not sure what you mean. I don't really have anything further to add than what I've already commented in this issue. As it stands, there's nothing preventing C++ code from using the bt_le_adv_start() API. The only issue is with the BT_LE_ADV_PARAM() macro that only C-code will be able to take advantage of.

@pabigot said:

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.

However I'm not familiar enough with C++ to say what the "look-alike" API alternative would be.

maksimmasalski · 2019-09-29T08:42:49Z

I was assigned to solve that issue. Can you give me please your vision of it?

@maksimmasalski I'm not sure what you mean. I don't really have anything further to add than what I've already commented in this issue. As it stands, there's nothing preventing C++ code from using the bt_le_adv_start() API. The only issue is with the BT_LE_ADV_PARAM() macro that only C-code will be able to take advantage of.

@pabigot said:

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.

However I'm not familiar enough with C++ to say what the "look-alike" API alternative would be.

Understood. Let's see how I can help you. If @pabigot can assist me with vision how C++ must be supported in Zephyr, it will be good first entry.

pabigot · 2019-09-29T18:16:45Z

The approach I've considered involves introducing material conditional on __cplusplus that constructs the struct value and adds an overload that takes it by reference. Example is below just for reference: it solves this for only one case, and there are many instances of this problem.

I don't think that approach should be selected until we've carefully considered other options, because it's not clean. As noted there is a workaround, so this isn't going to block anybody.

This issue is really not a good candidate for an initial contribution as it involves developing new core language API. The need to solve this issue should inform efforts like #19315 which aim to support C++ application development more generally, and which may include creation of a more general solution.

diff --git a/include/bluetooth/bluetooth.h b/include/bluetooth/bluetooth.h
index 61d8117237..022b6d5847 100644
--- a/include/bluetooth/bluetooth.h
+++ b/include/bluetooth/bluetooth.h
@@ -320,7 +320,7 @@ struct bt_le_adv_param {
   * @param _int_max   Maximum advertising interval
   */
 #define BT_LE_ADV_PARAM(_options, _int_min, _int_max) \
-               (&(struct bt_le_adv_param) { \
+               ((struct bt_le_adv_param) { \
                        .options = (_options), \
                        .interval_min = (_int_min), \
                        .interval_max = (_int_max), \
@@ -330,11 +330,18 @@ struct bt_le_adv_param {
                                       BT_GAP_ADV_FAST_INT_MIN_2, \
                                       BT_GAP_ADV_FAST_INT_MAX_2)
 
-#define BT_LE_ADV_CONN_NAME BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE | \
+#define BT_LE_ADV_CONN_NAME_S BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE | \
                                            BT_LE_ADV_OPT_USE_NAME, \
                                            BT_GAP_ADV_FAST_INT_MIN_2, \
                                            BT_GAP_ADV_FAST_INT_MAX_2)
 
+
+#ifdef __cplusplus
+#define BT_LE_ADV_CONN_NAME BT_LE_ADV_CONN_NAME_S
+#else
+#define BT_LE_ADV_CONN_NAME (&BT_LE_ADV_CONN_NAME_S)
+#endif
+
 #define BT_LE_ADV_CONN_DIR_LOW_DUTY \
        BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_ONE_TIME | \
                        BT_LE_ADV_OPT_DIR_MODE_LOW_DUTY, \
@@ -835,6 +842,13 @@ void bt_foreach_bond(u8_t id, void (*func)(const struct bt_bond_info *info,
  */
 
 #ifdef __cplusplus
+} /* extern "C" */
+
+int bt_le_adv_start(const struct bt_le_adv_param &param,
+                   const struct bt_data *ad, size_t ad_len,
+                   const struct bt_data *sd, size_t sd_len)
+{
+       return bt_le_adv_start(&param, ad, ad_len, sd, sd_len);
 }
 #endif
 /**

jhedberg · 2019-09-30T05:48:04Z

For the record, there are several other macros with the Bluetooth API that use the same approach, e.g. BT_LE_CONN_PARAM() and BT_LE_SCAN_PARAM()

mrfuchs · 2019-09-30T07:13:41Z

For the record, there are several other macros with the Bluetooth API that use the same approach, e.g. BT_LE_CONN_PARAM() and BT_LE_SCAN_PARAM()

As being said in the first comment, this is not exclusive to the Bluetooth stack -- json.h for example also has these macros: JSON_OBJ_DESCR_ARRAY, JSON_OBJ_DESCR_OBJ_ARRAY, JSON_OBJ_DESCR_ARRAY_ARRAY, JSON_OBJ_DESCR_ARRAY_NAMED and JSON_OBJ_DESCR_OBJ_ARRAY_NAMED.

pabigot · 2019-11-01T16:27:42Z

The worst "offender" of this is the struct bt_uuid infrastructure, where constants like BT_UUID_GATT_CHRC expand to the address of a temporary, which in turn gets used in expressions that take the address of a temporary struct bt_gatt_attr value when using BT_GATT_CHARACTERISTIC when defining services with BT_GATT_SERVICE_DEFINE.

If Bluetooth services are to be defined in C++ code I suspect we'll need a whole suite of parallel definitions to produce the declaration object hierarchies. The replace-pointer-with-reference approach in #18551 (comment) remains the best option I'm aware of so far, but it's far more invasive than I'd hoped.

daniel-james-sherwood · 2019-12-07T19:17:06Z

I recently discovered the same issue with some of the bt macros. It can be resolved (at least for gcc-8) by turning the inline struct initialiser into an array of [1] which prevents the compiler treating it as a temporary variable. For the example above this would look something like.

#define BT_LE_ADV_PARAM(_options, _int_min, _int_max) \
		((const struct bt_le_adv_param[1]) { { \
			.options = (_options), \
			.interval_min = (_int_min), \
			.interval_max = (_int_max), \
		 } })

pabigot · 2019-12-07T19:19:19Z

@daniel-james-sherwood Formatting fixed; thanks for the tip, that could be a very clean solution.

daniel-james-sherwood · 2019-12-07T19:25:12Z

Seems to work for me. For both const and non-const structs. Also doesn't appear to affect C builds.

pabigot · 2019-12-07T19:53:36Z

Agreed. It does expose a lot of implicit casts from void*, as well as some designated initializer order violations, but this seems to have promise. Gross conversion necessary to get the peripheral sample to work can be seen at https://github.com/pabigot/zephyr/commits/pabigot/cxx20ble

@daniel-james-sherwood If you want to prepare a PR for this I'll defer to you; otherwise I'll go through and convert everything necessary to get all in-tree Bluetooth samples (and tests?) building with C++ sometime in the first part of v2.2 development. Thanks for suggesting this way forward.

daniel-james-sherwood · 2019-12-07T20:53:23Z

You go ahead. My changes are mixed up with some others adding this C++ bindings to various APIs. Note you seem to have added an extra const to your first change.

danielschenk · 2021-01-30T21:16:55Z

I came across this issue due to a compilation error I'm getting, when I try to change one of Nordic's nRF Connect SDK examples from C to C++. In the peripheral_lbs example, when I change main.c to main.cpp, I'm getting this error:

[68/190] Building CXX object CMakeFiles/app.dir/src/main.cpp.obj
FAILED: CMakeFiles/app.dir/src/main.cpp.obj
C:\Users\320079877\ncs\v1.4.2\toolchain\opt\bin\arm-none-eabi-gcc.exe  -DBUILD_VERSION=v2.4.0-ncs2 -DKERNEL -DNRF52833_XXAA -DUSE_PARTITION_MANAGER=0 -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I../. -IC:/Users/320079877/ncs/v1.4.2/nrf/drivers/mpsl/clock_control -IC:/Users/320079877/ncs/v1.4.2/zephyr/include -Izephyr/include/generated -IC:/Users/320079877/ncs/v1.4.2/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/Users/320079877/ncs/v1.4.2/zephyr/subsys/settings/include -IC:/Users/320079877/ncs/v1.4.2/zephyr/subsys/bluetooth -IC:/Users/320079877/ncs/v1.4.2/nrf/include -IC:/Users/320079877/ncs/v1.4.2/nrf/lib/multithreading_lock/. -IC:/Users/320079877/ncs/v1.4.2/nrf/subsys/bluetooth/controller/. -IC:/Users/320079877/ncs/v1.4.2/nrfxlib/mpsl/include -IC:/Users/320079877/ncs/v1.4.2/nrfxlib/softdevice_controller/include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/cmsis/CMSIS/Core/Include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx/drivers/include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx/mdk -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/. -IC:/Users/320079877/ncs/v1.4.2/modules/debug/segger/rtt -IC:/Users/320079877/ncs/v1.4.2/modules/crypto/tinycrypt/lib/include -isystem C:/Users/320079877/ncs/v1.4.2/zephyr/lib/libc/minimal/include -isystem c:/users/320079877/ncs/v1.4.2/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/include -isystem c:/users/320079877/ncs/v1.4.2/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed -Os -fcheck-new -fno-exceptions -fno-rtti -imacros C:/Users/320079877/ncs/v1.4.2/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros C:/Users/320079877/ncs/v1.4.2/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-address-of-packed-member -Wno-unused-but-set-variable -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2/nrf/samples/bluetooth/peripheral_lbs=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2=WEST_TOPDIR -ffunction-sections -fdata-sections -nostdinc -MD -MT CMakeFiles/app.dir/src/main.cpp.obj -MF CMakeFiles\app.dir\src\main.cpp.obj.d -o CMakeFiles/app.dir/src/main.cpp.obj -c ../src/main.cpp
In file included from ../src/main.cpp:17:
../src/main.cpp: In function 'void main()':
C:/Users/320079877/ncs/v1.4.2/zephyr/include/bluetooth/bluetooth.h:591:30: error: taking address of temporary array
  591 |  ((struct bt_le_adv_param[]) { \
      |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
  592 |   BT_LE_ADV_PARAM_INIT(_options, _int_min, _int_max, _peer) \
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  593 |   })
      |   ~~
C:/Users/320079877/ncs/v1.4.2/zephyr/include/bluetooth/bluetooth.h:600:24: note: in expansion of macro 'BT_LE_ADV_PARAM'
  600 | #define BT_LE_ADV_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE, \
      |                        ^~~~~~~~~~~~~~~
../src/main.cpp:232:24: note: in expansion of macro 'BT_LE_ADV_CONN'
  232 |  err = bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad),
      |                        ^~~~~~~~~~~~~~

Apparently, after the fix provided for this issue, this is still an issue, but now in a slightly different way. Is this worth opening a new issue?

Note: when I make the struct in line 591 const, the problem is solved for me.

pabigot · 2021-01-31T00:02:05Z

That workaround is described at #24829 (comment), but it is still not legal C++. There is no known standard-conforming way to make the C API work in C++. #24829 (comment) describes the general solution for this problem.

Climax777 · 2022-02-18T14:25:06Z

I came across this issue due to a compilation error I'm getting, when I try to change one of Nordic's nRF Connect SDK examples from C to C++. In the peripheral_lbs example, when I change main.c to main.cpp, I'm getting this error:

[68/190] Building CXX object CMakeFiles/app.dir/src/main.cpp.obj
FAILED: CMakeFiles/app.dir/src/main.cpp.obj
C:\Users\320079877\ncs\v1.4.2\toolchain\opt\bin\arm-none-eabi-gcc.exe  -DBUILD_VERSION=v2.4.0-ncs2 -DKERNEL -DNRF52833_XXAA -DUSE_PARTITION_MANAGER=0 -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I../. -IC:/Users/320079877/ncs/v1.4.2/nrf/drivers/mpsl/clock_control -IC:/Users/320079877/ncs/v1.4.2/zephyr/include -Izephyr/include/generated -IC:/Users/320079877/ncs/v1.4.2/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/Users/320079877/ncs/v1.4.2/zephyr/subsys/settings/include -IC:/Users/320079877/ncs/v1.4.2/zephyr/subsys/bluetooth -IC:/Users/320079877/ncs/v1.4.2/nrf/include -IC:/Users/320079877/ncs/v1.4.2/nrf/lib/multithreading_lock/. -IC:/Users/320079877/ncs/v1.4.2/nrf/subsys/bluetooth/controller/. -IC:/Users/320079877/ncs/v1.4.2/nrfxlib/mpsl/include -IC:/Users/320079877/ncs/v1.4.2/nrfxlib/softdevice_controller/include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/cmsis/CMSIS/Core/Include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx/drivers/include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx/mdk -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/. -IC:/Users/320079877/ncs/v1.4.2/modules/debug/segger/rtt -IC:/Users/320079877/ncs/v1.4.2/modules/crypto/tinycrypt/lib/include -isystem C:/Users/320079877/ncs/v1.4.2/zephyr/lib/libc/minimal/include -isystem c:/users/320079877/ncs/v1.4.2/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/include -isystem c:/users/320079877/ncs/v1.4.2/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed -Os -fcheck-new -fno-exceptions -fno-rtti -imacros C:/Users/320079877/ncs/v1.4.2/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros C:/Users/320079877/ncs/v1.4.2/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-address-of-packed-member -Wno-unused-but-set-variable -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2/nrf/samples/bluetooth/peripheral_lbs=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2=WEST_TOPDIR -ffunction-sections -fdata-sections -nostdinc -MD -MT CMakeFiles/app.dir/src/main.cpp.obj -MF CMakeFiles\app.dir\src\main.cpp.obj.d -o CMakeFiles/app.dir/src/main.cpp.obj -c ../src/main.cpp
In file included from ../src/main.cpp:17:
../src/main.cpp: In function 'void main()':
C:/Users/320079877/ncs/v1.4.2/zephyr/include/bluetooth/bluetooth.h:591:30: error: taking address of temporary array
  591 |  ((struct bt_le_adv_param[]) { \
      |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
  592 |   BT_LE_ADV_PARAM_INIT(_options, _int_min, _int_max, _peer) \
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  593 |   })
      |   ~~
C:/Users/320079877/ncs/v1.4.2/zephyr/include/bluetooth/bluetooth.h:600:24: note: in expansion of macro 'BT_LE_ADV_PARAM'
  600 | #define BT_LE_ADV_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE, \
      |                        ^~~~~~~~~~~~~~~
../src/main.cpp:232:24: note: in expansion of macro 'BT_LE_ADV_CONN'
  232 |  err = bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad),
      |                        ^~~~~~~~~~~~~~

Apparently, after the fix provided for this issue, this is still an issue, but now in a slightly different way. Is this worth opening a new issue?

Note: when I make the struct in line 591 const, the problem is solved for me.

This worked for me too. Same problem as reported by the OP.

rhinodavid · 2022-02-21T01:39:32Z

+1 for the BT_LE_ADV_PARAM_INIT(_options, _int_min, _int_max, _peer) -- maybe a regression?

blainerothrock · 2022-06-16T21:22:45Z

I came across this issue due to a compilation error I'm getting, when I try to change one of Nordic's nRF Connect SDK examples from C to C++. In the peripheral_lbs example, when I change main.c to main.cpp, I'm getting this error:

[68/190] Building CXX object CMakeFiles/app.dir/src/main.cpp.obj
FAILED: CMakeFiles/app.dir/src/main.cpp.obj
C:\Users\320079877\ncs\v1.4.2\toolchain\opt\bin\arm-none-eabi-gcc.exe  -DBUILD_VERSION=v2.4.0-ncs2 -DKERNEL -DNRF52833_XXAA -DUSE_PARTITION_MANAGER=0 -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I../. -IC:/Users/320079877/ncs/v1.4.2/nrf/drivers/mpsl/clock_control -IC:/Users/320079877/ncs/v1.4.2/zephyr/include -Izephyr/include/generated -IC:/Users/320079877/ncs/v1.4.2/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/Users/320079877/ncs/v1.4.2/zephyr/subsys/settings/include -IC:/Users/320079877/ncs/v1.4.2/zephyr/subsys/bluetooth -IC:/Users/320079877/ncs/v1.4.2/nrf/include -IC:/Users/320079877/ncs/v1.4.2/nrf/lib/multithreading_lock/. -IC:/Users/320079877/ncs/v1.4.2/nrf/subsys/bluetooth/controller/. -IC:/Users/320079877/ncs/v1.4.2/nrfxlib/mpsl/include -IC:/Users/320079877/ncs/v1.4.2/nrfxlib/softdevice_controller/include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/cmsis/CMSIS/Core/Include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx/drivers/include -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/nrfx/mdk -IC:/Users/320079877/ncs/v1.4.2/modules/hal/nordic/. -IC:/Users/320079877/ncs/v1.4.2/modules/debug/segger/rtt -IC:/Users/320079877/ncs/v1.4.2/modules/crypto/tinycrypt/lib/include -isystem C:/Users/320079877/ncs/v1.4.2/zephyr/lib/libc/minimal/include -isystem c:/users/320079877/ncs/v1.4.2/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/include -isystem c:/users/320079877/ncs/v1.4.2/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed -Os -fcheck-new -fno-exceptions -fno-rtti -imacros C:/Users/320079877/ncs/v1.4.2/nrf/samples/bluetooth/peripheral_lbs/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -mcpu=cortex-m4 -mthumb -mabi=aapcs -imacros C:/Users/320079877/ncs/v1.4.2/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-address-of-packed-member -Wno-unused-but-set-variable -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2/nrf/samples/bluetooth/peripheral_lbs=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/Users/320079877/ncs/v1.4.2=WEST_TOPDIR -ffunction-sections -fdata-sections -nostdinc -MD -MT CMakeFiles/app.dir/src/main.cpp.obj -MF CMakeFiles\app.dir\src\main.cpp.obj.d -o CMakeFiles/app.dir/src/main.cpp.obj -c ../src/main.cpp
In file included from ../src/main.cpp:17:
../src/main.cpp: In function 'void main()':
C:/Users/320079877/ncs/v1.4.2/zephyr/include/bluetooth/bluetooth.h:591:30: error: taking address of temporary array
  591 |  ((struct bt_le_adv_param[]) { \
      |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
  592 |   BT_LE_ADV_PARAM_INIT(_options, _int_min, _int_max, _peer) \
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  593 |   })
      |   ~~
C:/Users/320079877/ncs/v1.4.2/zephyr/include/bluetooth/bluetooth.h:600:24: note: in expansion of macro 'BT_LE_ADV_PARAM'
  600 | #define BT_LE_ADV_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE, \
      |                        ^~~~~~~~~~~~~~~
../src/main.cpp:232:24: note: in expansion of macro 'BT_LE_ADV_CONN'
  232 |  err = bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad),
      |                        ^~~~~~~~~~~~~~

Apparently, after the fix provided for this issue, this is still an issue, but now in a slightly different way. Is this worth opening a new issue?
Note: when I make the struct in line 591 const, the problem is solved for me.

This worked for me too. Same problem as reported by the OP.

Same here.

pabigot added the bug The issue is a bug, or the PR is fixing a bug label Aug 21, 2019

pabigot added the area: C++ label Aug 21, 2019

pabigot mentioned this issue Aug 21, 2019

Tracking Issue for C++ Support as of release 2.1 #18554

Closed

8 tasks

aescolar added the priority: low Low impact/importance bug label Aug 22, 2019

rljordan-zz assigned rljordan-zz and jocelyn-li and unassigned rljordan-zz Aug 27, 2019

jocelyn-li removed their assignment Aug 28, 2019

chen-png self-assigned this Aug 28, 2019

jocelyn-li assigned maksimmasalski and unassigned chen-png Sep 17, 2019

maksimmasalski pinned this issue Sep 25, 2019

maksimmasalski unpinned this issue Sep 25, 2019

pabigot assigned pabigot and unassigned maksimmasalski Sep 29, 2019

pabigot mentioned this issue Sep 30, 2019

release: 1.14.1: add list of fixed bugs #19462

Merged

pabigot mentioned this issue Oct 8, 2019

C++ Support doesn't work #5695

Closed

pabigot mentioned this issue Nov 1, 2019

Bluetooth: rework to support C++20 designated initializers #20282

Merged

pabigot mentioned this issue Dec 14, 2019

treewide: avoid address-of-compound-literal idiom in headers #21397

Merged

carlescufi closed this as completed in #21397 Dec 18, 2019

Sir-Branch mentioned this issue Aug 25, 2021

json: Added element descriptor macro and C++ support progress #37941

Merged

yperess mentioned this issue Aug 3, 2023

RFC: Evolve C++ support with Pigweed #53851

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

pabigot commented Aug 21, 2019

pabigot commented Aug 21, 2019

aescolar commented Aug 22, 2019

jhedberg commented Aug 22, 2019

pabigot commented Aug 22, 2019

jhedberg commented Aug 27, 2019

pabigot commented Aug 27, 2019

maksimmasalski commented Sep 29, 2019

jhedberg commented Sep 29, 2019

maksimmasalski commented Sep 29, 2019

pabigot commented Sep 29, 2019

jhedberg commented Sep 30, 2019

mrfuchs commented Sep 30, 2019

pabigot commented Nov 1, 2019

daniel-james-sherwood commented Dec 7, 2019 •

edited by pabigot

Loading

pabigot commented Dec 7, 2019

daniel-james-sherwood commented Dec 7, 2019

pabigot commented Dec 7, 2019

daniel-james-sherwood commented Dec 7, 2019

danielschenk commented Jan 30, 2021

pabigot commented Jan 31, 2021

Climax777 commented Feb 18, 2022

rhinodavid commented Feb 21, 2022

blainerothrock commented Jun 16, 2022

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

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

Comments

pabigot commented Aug 21, 2019

pabigot commented Aug 21, 2019

aescolar commented Aug 22, 2019

jhedberg commented Aug 22, 2019

pabigot commented Aug 22, 2019

jhedberg commented Aug 27, 2019

pabigot commented Aug 27, 2019

maksimmasalski commented Sep 29, 2019

jhedberg commented Sep 29, 2019

maksimmasalski commented Sep 29, 2019

pabigot commented Sep 29, 2019

jhedberg commented Sep 30, 2019

mrfuchs commented Sep 30, 2019

pabigot commented Nov 1, 2019

daniel-james-sherwood commented Dec 7, 2019 • edited by pabigot Loading

pabigot commented Dec 7, 2019

daniel-james-sherwood commented Dec 7, 2019

pabigot commented Dec 7, 2019

daniel-james-sherwood commented Dec 7, 2019

danielschenk commented Jan 30, 2021

pabigot commented Jan 31, 2021

Climax777 commented Feb 18, 2022

rhinodavid commented Feb 21, 2022

blainerothrock commented Jun 16, 2022

daniel-james-sherwood commented Dec 7, 2019 •

edited by pabigot

Loading