• State Accepted Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 23 subscribers
  • Views 2797 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

MQTTClient.h vs stm32f7xx.h

Alex Shenfield

Hi,

I am currently playing about with MQTT using the MDK-Packs::Paho_MQTT pack in MDK-ARM. However, when I try and include the stm32f7xx.h file in my MQTT thread I get an error:

Arm\Packs\Keil\STM32F7xx_DFP\2.13.0\Drivers\CMSIS\Device\ST\STM32F7xx\Include\stm32f7xx.h(171): error:  #101: "SUCCESS" has already been declared in the current scope

which is because it is declared here:

typedef enum
{
SUCCESS = 0U,
ERROR = !SUCCESS
} ErrorStatus;

in stm32f7xx.h, and here:

/* all failure return codes must be negative */
enum returnCode { BUFFER_OVERFLOW = -2, FAILURE = -1, SUCCESS = 0 };

in MQTTClient.h.

This currently means that I can't include both files. My question is, is there a way to override this (or otherwise fix this) without editing the two header files (as they are "locked" for editing by MDK-ARM).

Regards,

Alex

Parents
  • +1

    This is a quality-of-implementation issue of both packages you're trying to combine. No experienced C programmer would ever define enum values like that, because doing so invites exactly the type of collision in the global namespace you're experiencing here.  Properly designed components apply name prefixes to all such globally visible names to avoid this pitfall.  In C++ one would use namespaces instead --- which are effectively nothing but syntactic sugar that end up doing the very same thing behing the scenes.

    So yes, as-is these are impossible to use together.  Changing just the headers would almost certainly not work, either, because these enum constants are going to appear all over the sources of the two components, too.  This needs to be fixed by either or both suppliers, eventually.

Reply
  • +1

    This is a quality-of-implementation issue of both packages you're trying to combine. No experienced C programmer would ever define enum values like that, because doing so invites exactly the type of collision in the global namespace you're experiencing here.  Properly designed components apply name prefixes to all such globally visible names to avoid this pitfall.  In C++ one would use namespaces instead --- which are effectively nothing but syntactic sugar that end up doing the very same thing behing the scenes.

    So yes, as-is these are impossible to use together.  Changing just the headers would almost certainly not work, either, because these enum constants are going to appear all over the sources of the two components, too.  This needs to be fixed by either or both suppliers, eventually.

Children