__HAL_RCC_USB_OTG_FS_CLK_ENABLE: declaration of 'tmpreg' shadows a previous local

[daniel-starke]

Describe the bug
The macro __HAL_RCC_USB_OTG_FS_CLK_ENABLE

STM32CubeF7/Drivers/STM32F7xx_HAL_Driver/Inc/stm32f7xx_hal_rcc_ex.h

Lines 845 to 852 in 08376dc

	#define __HAL_RCC_USB_OTG_FS_CLK_ENABLE() do { \
	__IO uint32_t tmpreg; \
	SET_BIT(RCC->AHB2ENR, RCC_AHB2ENR_OTGFSEN);\
	/* Delay after an RCC peripheral clock enabling */ \
	tmpreg = READ_BIT(RCC->AHB2ENR, RCC_AHB2ENR_OTGFSEN);\
	UNUSED(tmpreg); \
	__HAL_RCC_SYSCFG_CLK_ENABLE();\
	} while(0)

declares the local variable tmpreg and calls the macro __HAL_RCC_SYSCFG_CLK_ENABLE which is defined as

STM32CubeF7/Drivers/STM32F7xx_HAL_Driver/Inc/stm32f7xx_hal_rcc.h

Lines 468 to 474 in 08376dc

	#define __HAL_RCC_SYSCFG_CLK_ENABLE() do { \
	__IO uint32_t tmpreg; \
	SET_BIT(RCC->APB2ENR, RCC_APB2ENR_SYSCFGEN);\
	/* Delay after an RCC peripheral clock enabling */ \
	tmpreg = READ_BIT(RCC->APB2ENR, RCC_APB2ENR_SYSCFGEN);\
	UNUSED(tmpreg); \
	} while(0)

and also declares a local variable with the name tmpreg. This shadows the first declaration of the variable. I suggest the rename tmpreg in __HAL_RCC_USB_OTG_FS_CLK_ENABLE to something else.

How To Reproduce
Use __HAL_RCC_SYSCFG_CLK_ENABLE() somewhere in the source with the compiler flag -Wshadow set.

[ALABSTM]

Hi @daniel-starke,

Thank you for this report. Unfortunately, we could not reproduce the issue you described. Would you mind indicating the compiler you are using and its version? Any other detail on how to reproduce this warning is also welcome.

Thank you,

[ALABSTM]

Hi @daniel-starke,

According to our analysis, each one of the tmpreg has a distinct scope from the other one thanks to the do { ... } while(0) blocs surrounding each variable. We performed a couple of tests using the printf() function to print the value stored in the tmpreg variables and noticed no impact of the variable shadowing.

Moreover, the tmpreg variables are not meant to be used. This is the purpose from the UNUSED(tmpreg); lines in both macros. The read operation is only intended to create a delay as indicated in the comment.

Please do not hesitate to share your point of view. Any other detail on how to reproduce this warning is also welcome.

With regards,

[daniel-starke]

Yes, there is no functional impact. This is just an aesthetic issue due to the warning from the compiler which makes it harder to see real issues.

[carlosgalvezp]

@daniel-starke I fully agree this should be solved. However it's hard to expect 3rd-party libraries to fix stricter warnings.

You can include the headers with -isystem to let the compiler ignore those warnings, so you can still have your strict warnings active.

[daniel-starke]

True. But even if no fix is provided, reporting it may help others to evaluate their findings.

[ALABSTM]

Hi,

@carlosgalvezp, thank you for your comment. @daniel-starke, indeed, it is interesting to have this point reported whether for other users' attention or even for us at STMicroelectronics. Thank you again.

With regards,

[ALABSTM]

Hi,

Please allow me to close this issue. You can re-open it at any time in case any noticeable side effect is experienced due to this variable shadowing.

With regards