HAL functions using archaic terms - why?

[onderdelen]

Hi,

I am compiling the STM32U0 HAL library and I get errors like this one:

/Users/kiwanda/techniek/swexternals/STM32/HAL/Libraries/STM32U0xx_HAL_Driver/Inc/stm32u0xx_ll_comp.h: In function 'uint32_t LL_COMP_GetCommonWindowMode(const COMP_Common_TypeDef*)':
/Users/kiwanda/techniek/swexternals/STM32/HAL/Libraries/STM32U0xx_HAL_Driver/Inc/stm32u0xx_ll_comp.h:391:27: error: ISO C++17 does not allow 'register' storage class specifier [-Werror=register]
  391 |   register const uint32_t window_mode_comp_odd = (uint32_t)READ_BIT(COMPxy_COMMON->CSR_ODD, COMP_CSR_WINMODE);

I am using a C++ compiler and since C++14 the keyword register has been declared obsolete and useless. I fully agree with this step, all the more since we are writing SW here on ARM Cortex:

When writing software for ARM Cortex, which is a Load/Store architecture RISC processor, EVERYTHING goes through a register. The register keyword is therefore completely meaningless, useless and superfluous in this context.

I would like to ask ST to write the HAL libraries in such a way that they can also be used in modern contexts like the one I prefer to use. Checking the library with a C++ compiler is very effective since it finds anomalies and errors that (lax) C compiler disregard.

with best regards,

Ewout Boks

Ewout Boks

[TDK]

Mistakes happen. Looks like the "register" keyword is used exactly twice in the entire HAL library, just where you show it. Hardly a systemic issue.

[gbm]

register is not "completely meaningless". It may be used to ensure that error is signaled if & (address of) operator is used.

[Tesla DeLorean]

Well it depends on the compiler.

Ideally it can hold the values in the working registers, but auto variables can be held on the stack.

[Andrew Neil]

---

@onderdelen wrote:

I am using a C++ compiler

---

But the HAL is C - not C++

[mfgkw]

This is true.

But you should be able to write your app in C++ (which works generally).

When you #include the ST stuff a C++ compiler will complain about the register even if the #include is inside an extern "C" block.

[Pavel A.]

You can open an issue on GitHub against this code.

[Saket_Om]

Hello @onderdelen 

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: 221904 (This is an internal tracking number and is not accessible or usable by customers).

[Andrew Neil]

---

@mfgkw wrote:

When you #include the ST stuff a C++ compiler will complain...

---

right - didn't spot that it's in a header

PS:

@Saket_Om  This has come up before; eg, Is the "register" storage class specifier necessary in STM32 LL interfaces?

[Ozone]

C++ might complain or even forbid it, but I cannot find such information regarding plain C.
I suppose compilers will continue to support it to maintain backward compatibility.

On a related note, I learned C before the first ANSI standard, when there was only K&R.
And at that time, register and auto were still a thing.
As I heard the idea came from the original developers, using a PDP-11 system.
Where it probably made sense considering that the first toolchains had poor or no optimisation at all, due to memory constraints alone.