Const correctness about stm32cubef4

[RKOUSTM]

Hi @jrahlf,

First, allow me to thank you for your contribution. The final decision of our technical committee is no plan to add a const inside the function. The reported point is already highlighted during the MISRA-C 2012 compliance rework (Rule-8.13). It has been decided, from the quality point of view, to derogate this rule as fixing it will break the compatibility with almost all HAL APIs and then update all examples and applications within the Cube deliverable and also on user application side.

Please, allow me to close this issue. Thank you for your comprehension.

With regards,

[RKOUSTM]

Hi all,

We have reported your feedback to our technical committee and after discussion an update will be started soon to add the use of the const qualifier. We still cannot share a date for the moment due to the huge effort required for the different components. We will keep you informed.

All duplicated issues will remain closed. This one will be kept open to track the point.

With regards,

[jrahlf]

Hi @RKOUSTM,

As said by @atsju, adding const to function parameters does not break any API. It merely informs the caller that the function will not / cannot modify the callers' parameters.

Hence I find this decision outrageous, especially since it is very easy to implement from a technical point of view. Give any intern a few weeks and he will do it for you. It is almost impossible to screw it up because the compiler will tell you if do something wrong (unless you start using const casts).

I was really cheering for ST since they opened this public bug tracker and published the STM32Cube pack creator tool, which should boost the STM32 software ecosystem through continuous and transparent improvements.
But this seems like a big step backwards..

Also, this has been in your pipeline for several years by now (as mentioned by @ALABSTM). This must be a joke.
This issue should not be closed yet (but all the duplicates should be).

[kjsdf7wr3]

It has been 2 years now, @RKOUSTM, @ALABSTM
Can we get a progress update?

[XaviDCR92]

Hi @RKOUSTM,

As said by @atsju, adding const to function parameters does not break any API. It merely informs the caller that the function will not / cannot modify the callers' parameters.

It might break user code that uses function pointers against the API, but still that's not a reason not to make it const-correct.

@RKOUSTM , if you are worried about breaking user code, introduce a new major version of the API and encourage users to move to it, as I have previously stated. But please, do not close this issue. That would be a irresponsible move from your side.

[theadib]

Hello AlabSTM,

I also have to cast away my const declared pointers. Nowadays that is a safety issue.
I would like to support you but I do not know exactly how to help//provide_code/review_code.

Generally in interface code I2C UART USB that applies to all Write or Transfer functions.

Regards, Adib.

[jrahlf]

🎂 🎂 🎂 🎂 1 year anniversary 🎂 🎂 🎂 🎂

[XaviDCR92]

The title says it all. Please fix the drivers so that all read-only pointers are correctly marked as const. I am sure many users will appreciate this.

Thank you.

+1
For the time being, I'm patching const-correctness issues on a branch inside my fork of STM32CubeF4 as soon as I find them, so a pull request can be submitted if STM32 does not fix this in a short term.

[ALABSTM]

Hi @jrahlf,

Thank you for your report.

Would you mind indicating the compiler you used and its version to have the warning? Would you also mind copying the warnings logged? This would help identify the driver parts you have this issue with.

Thank you,

[XaviDCR92]

@ALABSTM There must be other non-const correct functions out there, but at least this one should be fixed: https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_gpio.h#L225

[ALABSTM]

Hi @XaviDCR92,

Would you mind indicating the compiler you are using and its version or, at least the IDE and its version? This would help our development teams better address your request.

Thank you,

[XaviDCR92]

Hi @ALABSTM
I am using arm-none-eabi-gcc 6.3.1 with -Wall, but const-correctness does nothing to have with the compiler. As @jrahlf remarked, all read-only pointers should be marked as const for increased safety. Please read this article from Wikipedia about const-correctness for further reference.

[ALABSTM]

Hi both of you,

Thank you for your reply @XaviDCR92. This request will be forwarded to our development teams. I will be back to you as soon as they provide me with their answer.

With regards,

[ALABSTM]

Hi @jrahlf and @XaviDCR92,

Our development teams agreed on the point you raised. They said they have planned a global update of the HAL and LL drivers since a while.

However, this is likely to require some time to be deployed. We cannot share a date for the moment, but we will do our best to have such a global update deployed and released soon. We count on your patience.

Thank you again for having tackled the subject. Take care and stay safe.

With regards,

[XaviDCR92]

Hi @ALABSTM ,
Thank you for your support. Please notify us once you upload this update.

[XaviDCR92]

Hello @ALABSTM , are there any updates regarding this issue?
Thank you very much

[ALABSTM]

Hello @XaviDCR92,

Unfortunately, our development teams have not shared a date yet. The update requires considerable amount of work. We count on your patience and comprehension.

With regards,

[jrahlf]

Are there any updates on this?

[atsju]

Hi @RKOUSTM ,
I agree this is a big workload to make all changes. And yes the API of the HAL will change in that way that the function prototype is slightly different.
BUT there is no need to change the examples neither the user code. Indeed adding this const only says that the function itself will no modify the data but the user buffer could be non const without any compilation warning or issue. The proposed changes would only make your code cleaner and has absolutely no impact for your customer (I am part of those customers who do not want the API to change).
Best regards,

[XaviDCR92]

I totally agree with @atsju . API-breaking changes must not be avoided, but instead must be introduced in a new major version. You can still maintain your current API with minor revisions and bugfixes for some time e.g.: 18 months by releasing minor versions, while encouraging everyone to move eventually into the safer, const-correct API.
This is mostly what most FOSS libraries out there do (see mbedtls or esp-idf as examples) in order to keep a good balance between new features, safety and backwards compatibility.

[CanastraRF]

@RKOUSTM
Dear Support
I add const to your API every time a new release is available.
So I can share my modification if you like.

[atsju]

It might break user code that uses function pointers against the API, but still that's not a reason not to make it const-correct.

I honestly I didn't see this one. Good point. Anyway as the API changes the major release is justified. Even if it takes a year until next major the ticket shouldn't be closed.

[XaviDCR92]

Hello @ALABSTM , are there any news regarding this issue?

[ALABSTM]

Hello everybody,

The subject is progressing, slowly but surely. An artifact has been logged into our internal database since a while.

As previously said, it takes us time to have the update spread to all series, have all related test campaigns finished, and possibly address potential impact on ecosystem tools. Not to mention other topics with same priority as this one or higher.

Once again, we count on your comprehension and patience and we do thank you for the interest you are showing.

With regards,

[ALABSTM]

ST Internal Reference: 98091

[jrahlf]

Are we going for 2 years?

[ALABSTM]

Hi @kjsdf7wr3 and all,

From our side, the action is progressing slowly but surely. We started deploying the use of the const qualifier. Some drivers of some series have already been published after having been updated and there is more to come:

• stm32g4xx_hal_driver#203c724864
• stm32l1xx_hal_driver#b23faef1e2
• stm32l5xx_hal_driver#e9e26cbb9f

With regards,

[atsju]

Hi @RKOUSTM, @ALABSTM,
has there been any improvement since 8 month ago ? Do not hesitate to share the progress. Slowly for sure...

Could you upper the priority for SPI, UART and other widely used communication peripheral with Tx buffers ?
https://github.com/STMicroelectronics/stm32u5xx_hal_driver/blob/2e1d4cdb386e33391cb261dfff4fefa92e4aa35a/Inc/stm32u5xx_hal_spi.h#L842

[ALABSTM]

Hi everyone,

The deployment of the const keyword is being deployed slowly but surely as said before. Below the example of the HAL UART driver. In the meanwhile, please allow me to close this issue. This topic will be tracked through our internal trackers till it is fully deployed.

STM32CubeF4/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_uart.h

Lines 722 to 726 in 964d632

	HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, const uint8_t *pData, uint16_t Size, uint32_t Timeout);
	HAL_StatusTypeDef HAL_UART_Receive(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout);
	HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, const uint8_t *pData, uint16_t Size);
	HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size);
	HAL_StatusTypeDef HAL_UART_Transmit_DMA(UART_HandleTypeDef *huart, const uint8_t *pData, uint16_t Size);

With regards,