Multiple definitions warning for PAGESIZE

[dknipe]

I am getting a multiple definitions warning when compiling due to Inc/Legacy/stm32_hal_legacy.h redefining PAGESIZE, which is already defined in limits.h (in the RTEMS lib). I am using STM32H7xx specifically, but this issue appears to affect all of  the STM32 HALs.

arm-rtems4.11/include/limits.h line 445

#define PAGESIZE                (1<<12)

STM32H7xx_HAL_Driver/Inc/Legacy/stm32_hal_legacy.h

#define PAGESIZE                      FLASH_PAGE_SIZE

When searching I found some corespondents about a pull-request on the stm32f4x HAL to remove this definition from the HAL.

https://www.mail-archive.com/devel@rtems.org/msg28694.html

From what I can tell this definition doesn't get used anywhere, and I don't see any reason why the HAL should be redefining something that is already defined by the compiler. Just like the person that created that pull request, I also tried simply removing the PAGESIZE definition from stm32_hal_legacy.h and didn't have any issues recompiling.

Am I missing something here? Is there a reason this is being redefined, or is this possibly just an oversight?

[dknipe]

I should add that while you can see my compiler is rtems, I believe this is a POSIX implementation/definition. I'd expect other compilers to have this problem as well.

https://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html

If this isn't universal, then I guess I'm not 100% certain the best way to handle it and maintain portability.

[Tesla DeLorean]

>>Am I missing something here? .. redefining something that is already defined by the compiler.

The "compiler" isn't defining anything, its defined by an include file that's getting pulled in for HAL legacy user. The PAGESIZE was the old model, and FLASH_PAGE_SIZE comes from the part specific include file now there are a million STM32 variants.

You're probably not seeing it used because you have no legacy code in your project. The scope of potential usage is perhaps a tad bit bigger than your project.

Sure it's a rather generic name, and it's polluting the name space, but do you need to pull in this include file? RTEMS could have used something more unique, and been fine. Just how much of the HAL do you need to pull in?

#define RTEMS_PAGESIZE                (1<<12) // Like this for 4KB RAM Pages

Heck, add an #ifdef / #undef construct after pulling the HAL stuff

[dknipe]

We are not including this directly. "Legacy/stm32_hal_legacy.h" is being included by stm32h7xx_hal_def.h, which is used throughout the HAL. It gets pulled in whenever we include <hal/stm32h7xx_hal.h>.

https://github.com/STMicroelectronics/stm32h7xx_hal_driver/blob/master/Inc/stm32h7xx_hal_def.h

hal/stm32h7xx_hal.h includes stm32h7xx_hal_conf.h, which is very similar to this:

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/STM32H743I-EVAL/Examples/FMC/FMC_NOR/Inc/stm32h7xx_hal_conf.h

stm32h7xx_hal_conf.h then includes other headers (depending on config), which in turn include stm32h7xx_hal_def.h.

Edit: I didn't address it, but yes, I am fully aware that the compiler isn't defining it directly. It's defined in an include file that comes with the rtems compiler. I simply said "compiler" because I felt it was close enough and was a lot more concise.

We do currently have #ifdef/#undefs. But it's a maintenance problem because the problem will pop up somewhere else if someone includes <limits.h>. In our repository I am removing the definition from stm32h7xx_hal_def.h because we don't need it and cannot have any compiler warnings. But this poses it's own maintenance problem if we ever update our HAL from the git repo.

---

@Tesla DeLorean wrote:

RTEMS could have used something more unique, and been fine.

---

This HAL comes from the STMicroelectronics github, is this not produced by STMicro?