__STDC_LIMIT_MACROS in critical.h

[micromint]

Description

• Type: Question
• Related issue: Fix inclusion (board.c and critical.c) #1920
• Priority: Minor

---

Question

Should __STDC_LIMIT_MACROS be reinstated in critical.h?

When using a C++ compiler __STDC_LIMIT_MACROS should be declared to use datatype limit macros from stdint.h, such as the UINT32_MAX used in platform/mbed_critical.c. This declaration was added to hal/common/critical.c in #1920, but was removed when the mbed code was reorganized and declarations in critical.c moved to platform/critical.h. Should it be reinstated?

mbed_critical.c appears to be the only C source file in the mbed base library that does not build properly with a C++ compiler, e.g. using --cpp in ARMCC.

#define __STDC_LIMIT_MACROS
#include <stdbool.h>
#include <stdint.h>
#include <stddef.h>

[bridadan]

We haven't seen any build issues in our nightlies, what version of ARMCC are you using? And you can paste your commands and full logs?

[micromint]

The issue only occurs if you compile C sources with a C++ compiler, e.g. 'armcc -cpp'. Current mbed build scripts compile C sources with the C compiler, e.g. 'armcc' without -cpp. Previously the __STDC_LIMIT_MACROS declaration was required in some cases so it was added in #1920 . That declaration was removed with the mbed code reorganization, but couldn't find the justification since some of the old history is difficult to get after all the file moves in the source tree. Possibly @0xc0170 can comment on this since he posted #1920.

This is certainly a minor issue. But some developers prefer using a C++ compiler with C sources due to stricter syntax checking and other benefits.

Another alternative would be to replace the reference to UINT32_MAX on that assertion,

MBED_ASSERT(interrupt_enable_counter < UINT32_MAX);

with something like

MBED_ASSERT(interrupt_enable_counter < (uint32_t)(-1));

which would not require declaring __STDC_LIMIT_MACROS to build that source file with a C++ compiler.

Currently that is the only C source line in the mbed base library that does not build properly with a C++ compiler.

[bridadan]

Thanks for explaining a bit more! Any thoughts @geky, @c1728p9 , @0xc0170?

[c1728p9]

This was removed in PR #2054 with commit 26726cc. It doesn't look like it was removed to fix a bug or anything. I don't see a problem with adding it back. A more general solution, such as a command line define would be preferable, though.

[0xc0170]

A more general solution, such as a command line define would be preferable, though.

Not certain we want to allow c++ files to use stdint header file? If this uin32t_max would be in the c++ file, it should have been changed to use c++ numeric_limits. However, this is C file, thus the header file inclusion is correct.

I would add STD LIMITS macro to the code file, header file does not require it at all, neither should any other file that pulls in critical.h.

The proposal:

//critical.c file

#define __STDC_LIMIT_MACROS
// here we could explicitly include stdint.h and state, that this is because 
// we use UIN32_MAX macro thus the above macro enables it to be compatible when this source file is compiled by C++ compiler
#include "platform/critical.h"

[micromint]

@c1728p9 Thanks for referencing the PR that removed the declaration. Was not able to find it via simple search.

@0xc0170 Good suggestion. Adding the declaration on mbed_critical.c would be a good alternative. It allows building C sources with a C++ compiler without impacting other source files that include critical.h.

[geky]

The profiles in the tools support c-specific flags:
https://github.com/ARMmbed/mbed-os/blob/master/tools/profiles/small.json#L31

Could -D__STDC_LIMIT_MACROS be added to the profile that specifies armcc --cpp?

[micromint]

@geky Thanks for your suggestion. Since mbed_critical.c is the only C source file using UINT32_MAX, the proposal by @0xc0170 seems a better alternative than changing CFLAGS for all builds.

[micromint]

Closed in favor of #3305