search

STMicroelectronics / STM32CubeG0

STM32Cube MCU Full Package for the STM32G0 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
166 stars 75 forks source link

Lint suppressions in FreeRTOS have a trailing full-stop character which pc-lint rejects #48

Closed pmacfarlaneptl closed 8 months ago

pmacfarlaneptl commented 8 months ago

Setup

We're working on a project that includes both an STM32G0 and and STM32L4+ MCU. We are using FreeRTOS on both boards. We build with CubeIDE 1.14.0.

We are getting our FreeRTOS source code from this repository rather than the one provided by CubeIDE. We are using release 1.6.1 of this repo.

We use pc-lint v1.4.1 to run static analysis on both of our projects.

Bug description

The FreeRTOS source includes lines like the following, in Middlewares/Third_Party/FreeRTOS/Source/tasks.c:

#undef MPU_WRAPPERS_INCLUDED_FROM_API_FILE /*lint !e961 !e750 !e9021. */

This is rejected by pc-lint, as follows:

Middlewares/Third_Party/FreeRTOS/Source/tasks.c 47:44 error 72: bad option '!e9021.': invalid message number for !e

We have determined that it is the full-stop at the end of !e9021. that causes the problem. If we remove the full-stop, lint works as expected.

The same issue is in other source files too: stream_buffer.c, timers.c, queue.c.

Other notes

I've submitted this bug report in the STM32CubeG0 repo, but I suspect it exists for other flavours of STM32 too. It's certainly also a problem on the STM32L4+ repo.

TOUNSTM commented 8 months ago

Hello @pmacfarlaneptl,

Thank you for your contribution. Unfortunately we don't treat aspect related to Third_Party files in our GitHub repositories. As these files are out of the scope of STMicroelectronics, any modifications concerning stream_buffer.c, timers.c, queue.c and tasks.c files are not implemented by our technical team. All aspects related to FreeRTOS are not handled in our GitHub repositories. They are rather treated at FreeRTOS GitHub.

Please allow me to close this issue now. Thank you again for your contribution.

With regards,