Function signature uint32_t nrf_rtc_event_address_get(..) in the SDK14.2 is wrong, won't compile

[butch]

The comments (and the name of the function) say it returns an address, of an event register.  So the return type should be a pointer type?  This causes compile errors on stricter compilers.

components/nrf_drivers/hal/nrf_rtc.h

nRF5_SDK_14.2.0_17b948a

arm-none-eabi-gcc version 4.9.3 compiling as C++

[haakonsh]

Hey butch,

It is in fact not a pointer, but a uint32_t address that you must pass as an argument to nrf_drv_ppi_channel_assign(). 

Cheers,

Håkon.

[butch]

It meets the definition of a pointer: "value refers to (or points to) another value stored elsewhere in the computer memory using its memory address." (wikipedia)

You say the type is suitable for a parameter to another API function (nrf_drv_ppi_channel_assign()) but to me that only means that the problem is present throughout your API. It might work, but I think it is obfuscates and bloats code.

Consider trying to trigger a gpiote task. nrf_gpiote_task_addr_get() also returns a uint32_t, where it should return uint32_t* (a pointer.) Nieve code to trigger the task is:

* (nrf_gpiote_task_addr_get(NRF_GPIOTE_TASKS_OUT_0)) = 1;

But at least on my compiler that generates error: "invalid type argument of unary '*'" I think most compilers would complain about that, but I suppose it depends on the compiler and the compiler settings.

So to get past the error, you must cast:

* (uint32_t*) (nrf_gpiote_task_addr_get(NRF_GPIOTE_TASKS_OUT_0)) = 1;

The casting would be unnecessary if the API used pointer types, and the API would fit most programmer's mental model of what is happening.

[haakonsh]

Yes, you are correct in that the API would be more streamlined if it used a pointer, but the signature definition clearly states that it returns a uint32_t and not a pointer.