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.

[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?

[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).

 

[onderdelen]

Thanks everyone for putting in their worthy knowledge!

Yes I know C still supports register. But HAL supposedly also supports C++ environments. The lines are not clearly drawn since C is a subset of C++ with a few exceptions such as this one. Based on what compilers docs such as Keil or gnu arm say, usage of the register keyword is not encouraged at all.

Over the years I have used in projects a number of the HAL libraries. After importing them locally, typical errors I get (compiling with a C++ compiler) :

• local variables shadowing global variables. Apparently C does not mind but C++ does not approve of this.
• comparing signed and unsigned variables in a boolean expression.
• the register keyword.
• variables that were declared but not used.

These were all minor thing and did not stop me from using the libraries with a C++ compiler. All in all my impression is that ST strives to get rid of annoying bugs like these and the quality of the HAL libraries has improved quite well over the years.

As a last note it can be said that the HAL library is already an object-oriented library, with all the XXX_HandleTypeDef structs holding the object parameters, Init() and DeInit() functions and such. Wrapping a class around it is not hard, so I hope this encourages ST to think more of the growing legion of C++ users like me or even publish a few classes themselves in the HAL library.

Ewout Boks

[Andrew Neil]

@onderdelen this should now be fixed:

https://community.st.com/t5/stm32-mcus-embedded-software/register-specifier-in-cube-ll/m-p/870717/highlight/true#M71703