Why does code generated from CubeMX not adhere to the C standard?

[fsch]

The C standard says in 7.1.3 Reserved identifiers:

"All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use."

Yet the code CubeMX generates is full of __HAL... identifiers. Is there a reason for that?

Also, the code does not include needed headers. E.g. stm32f4xx_hal.h uses uint32_t without including stdint.h.

Are there efforts to improve on this kind of issues?

[Pavel A.]

> Also, the code does not include needed headers. E.g. stm32f4xx_hal.h uses uint32_t without including stdint.h.

This works because all stm32f..._hal.h include a specific model file defined by CMSIS spec, and these .h files include stdint.h

So no miracles there.

The Cube generated header main.h typically includes stm32f..._hal.h , so it pulls stdint.h into all generated source files.

> Are there efforts to improve on this kind of issues?

There are so many real issues and problems with that codebase.

Anyway if they changed something and break existing code, users will be very upset.

-- pa

[fsch]

Both the things I asked about should basically be done to make your code more stable. Using reserved identifiers can break your code on compiler updates and not inclusing what you use but relying on others to include it can break your build when restructuring your project or maybe also on parallelized builds.

[Tesla DeLorean]

This would seem to be consistent with ANY use, and has more than one letter.​

Stylist nit-pick ranks pretty low on the priority scale. ​I don't see it significantly impeding portability.

[fsch]

The letter is not important here. Its an underscore followed by an underscore, which is reserved and using it makes for non-compliant C code. It's a software quality issue that should not have happened in the first place. It's a sign of "we do not know what we are doing".

We (as a company) are currenty undergoing certification and need to answer why "our" code is throwing hundreds of warnings. ... So I was interested in getting an answer here. A bit more than "it works, so where is the problem?".

[Ozone]

> We (as a company) are currenty undergoing certification and need to answer why "our" code is throwing hundreds of warnings.

And you use Cube / Hal ?

Haven't you looked closely into it before ?

[fsch]

Nope. Start-up in the process of growing and professionalization. It just worked and "form followed function" ...

I am here for a few weeks now and first thing I did was updating the compiler and adding warning switches. Since then, I am cleaning up, modularizing and looking into the certification process. ...

And even now I did not take a closer look at HAL, just looking into the compiler warnings.Our own code has priority now. Are you suggesting, a closer look will make me cry?

[Ozone]

> Are you suggesting, a closer look will make me cry?

Depends on your mental robustness.

Check the forum entries regarding Cube/Hal bugs, code quality / test quality issues, and general complaints.

It is a free-of-charge lib to provide the superficial beginner a quick start, and mostly concentrates on sunny-side scenarios and examples. Nothing more, IMHO.

[Pavel A.]

Just FYI, they have many "serious" customers which demand compliance with various rules.

Even the horrible MISRA C :(

-- pa

[TDK]

> I am here for a few weeks now and first thing I did was updating the compiler and adding warning switches.

I think you'll be hard pressed to find free software of any nontrivial complexity that compiles with nary a warning under "-Wall". C preprocessing is a mess, it always has been, it always will be.

I think of ST as primarily a hardware company. They put out an incredible set of silicon, and an excellent reference manual. If you expect near perfection, stick with the RM and roll your own firmware, you won't be disappointed. If you want a higher level interface, you're going to have to live with a few software bugs. Using macros that start with __HAL is so far down on the list of priorities.