cancel
Showing results for 
Search instead for 
Did you mean: 

'register' specifier in Cube/LL

waclawek.jan
Super User

I have a bunch of following warnings:

c:/programs/ARMtools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F1xxxx/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_gpio.h: In function 'void LL_GPIO_SetPinMode(GPIO_TypeDef*, uint32_t, uint32_t)':
c:/programs/ARMtools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F1xxxx/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_gpio.h:343:22: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
  343 |   register uint32_t *pReg = (uint32_t *)((uint32_t)((uint32_t)(&GPIOx->CRL) + (Pin >> 24)));
      |

in several LL headers.

Can this please be fixed in some suitable way? One way to do that might be to replace the 'register' specifier by a macro, which would be defined based on the __cplusplus  standard preprocessor macro and its value. A simple version would be to add

#if __cplusplus >= 201703L
#define register
#endif

to each header where this occurs, but I am not a C++/build-environment specialist so don't know whether this may have some unwanted effect I am not aware off.

Thanks,

JW

1 REPLY 1
Andrew Neil
Super User

Same Issue recently:

HAL functions using archaic terms - why? 

(the "archaic term" is the register specifier)

 

PS:

and from 2018:

Is the "register" storage class specifier necessary in STM32 LL interfaces?

TL;DR: No.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.