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 ?

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

[fsch]

Thanks for all the answers.

I read some things about ST HAL and looked at its code and it becomes more likely we will drop it rather sooner than later either for Chibi HAL or for a plain old hand-written layer. Sure, ST is a great hardware company with really good documentation. Thumbs up for that.

When it comes to certification, we are currently talking to ST directly and we will see what comes out of that.

Cheers