Comments (29)
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,
from stm32cubef4.
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,
from stm32cubef4.
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).
from stm32cubef4.
It has been 2 years now, @RKOUSTM, @ALABSTM
Can we get a progress update?
from stm32cubef4.
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.
from stm32cubef4.
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.
from stm32cubef4.
🎂 🎂 🎂 🎂 1 year anniversary 🎂 🎂 🎂 🎂
from stm32cubef4.
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.
from stm32cubef4.
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,
from stm32cubef4.
@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
from stm32cubef4.
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,
from stm32cubef4.
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.
from stm32cubef4.
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,
from stm32cubef4.
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,
from stm32cubef4.
Hi @ALABSTM ,
Thank you for your support. Please notify us once you upload this update.
from stm32cubef4.
Hello @ALABSTM , are there any updates regarding this issue?
Thank you very much
from stm32cubef4.
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,
from stm32cubef4.
Are there any updates on this?
from stm32cubef4.
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,
from stm32cubef4.
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.
from stm32cubef4.
@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.
from stm32cubef4.
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.
from stm32cubef4.
Hello @ALABSTM , are there any news regarding this issue?
from stm32cubef4.
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,
from stm32cubef4.
ST Internal Reference: 98091
from stm32cubef4.
Are we going for 2 years?
from stm32cubef4.
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:
With regards,
from stm32cubef4.
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
from stm32cubef4.
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
With regards,
from stm32cubef4.
Related Issues (20)
- HAL_SRAM_Write_16b is 32b HOT 5
- Trigger event triggered in MX_TIMx_Init (TIM_Base_SetConfig) causing triggering of slave timers initialised first HOT 9
- __HAL_RCC_APB2_FORCE_RESET cause mcu reset! HOT 5
- STM32 lwIP Ethernet driver Tx deadlock HOT 9
- STM32F429 + LAN8742a (custom board) problem with lwip HOT 2
- STM32CubeF4 (this repo) vs CubeMX/IDE Downloads
- Unnecessary 64-bit calculations result in 700+ bytes increase in firmware size HOT 2
- UART race condition bug associated with HAL_LOCK() function location HOT 2
- When the timer is initialized, the ARR register will be miscalculated.
- lwIP project could not work in stm32cubeide HOT 2
- PWM oversight on STM32CubeMX + HAL combination HOT 5
- Unwanted I2S DMA output HOT 1
- cmsis_os2.c -> osThreadDetach function missing HOT 2
- BUG : Wrong check of file size in the ymodem.c file HOT 2
- Unused variable warnings with USE_FreeRTOS_HEAP_1 defined HOT 2
- not nice formatted HOT 3
- How to use FPU to actively trigger IDC interrupt HOT 1
- CubeMX does not handle custom PHY anymore HOT 4
- Please publish v1.28.1 tag HOT 1
- Cannot exclude BSP submodules when pulling STM32CubeF4 into superproject HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stm32cubef4.