[HELP] the type of INT32_C(0) is not int32_t in xtensa

[Y334275]

Description

When I was trying to replace the NuttX version that PX4 depends on with 12.12, I encountered some compilation errors. Here is the specific compilation error:

PX4-Autopilot/src/modules/navigator/mission_base.cpp:76:60: error: no matching function for call to 'constrain(int32_t&, long long int, long int)'  
  76 |                 const int32_t start_index = `math::constrain`(_mission.current_seq, `INT32_C(0)`, int32_t(_mission.count) - 1);  
     |                                             ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
compilation terminated due to -Wfatal-errors  

In this case, math::constrain is a template function that expects all arguments to be of a single type (which should be int32_t here). However, the type of INT32_C(0) is not int32_t.

I searched for INT32_C and found its definition in arch/xtensa/include/inttypes.h:

#define INT32_C(x)  x ## ll  
#define INT64_C(x)  x ## ll  

This shows its definition is the same as INT64_C, both being long long int. But the _int32_t defined in xtensa is long int (in arch/xtensa/include/types.h). Is this a mistake?

Verification

• I have verified before submitting the report.

[piyushtripathi9424]

Hi, I am a beginner and would like to help with this issue.
From the description, it seems INT32_C(x) should produce a value of type int32_t (which is long int on xtensa), but currently it expands to xll (long long int).
If this is confirmed to be a bug, I would like to submit a small patch to adjust the INT32_C macro so that its type matches int32_t.
Could you please confirm what the correct definition for INT32_C on xtensa should be and if you are open to a PR for this?

[Y334275]

@piyushtripathi9424 Thanks for your reply. After change #define INT32_C(x) x ## ll to #define INT32_C(x) x ## l, the error disappeared. However, due to some other issues, I can't compile the program successfully right now, so I can't verify whether this modification affects system stability at runtime.
After reviewing the code related to the INT32_C macro, I believe the impact of this modification should be minimal. If possible, I am happy to open a PR to fix this issue.

[fdcavalcanti]

Hi,
Please read the discussion in #15755 and #16022.

[piyushtripathi9424]

Thanks for the update, @Y334275 , and for testing the change from INT32_C(x) x ## ll to INT32_C(x) x ## l. That matches the expectation that INT32_C should have the same underlying type as int32_t on xtensa, so it makes sense that it fixes the template mismatch in math::constrain. I will go through the discussion in #15755 and PR #16022 as suggested to make sure the change is consistent with previous decisions, and then I’d be happy to help with or review a PR that adjusts the macro accordingly.

[Y334275]

@fdcavalcanti Hi, sorry to bother you. I read all discussions on #15755 and #16022, but I still can't understand why INT32_C is defined as x ## ll. Shouldn't it be x ## l instead?

[fdcavalcanti]

Interesting. Seems like a mistake, as I can't recall the reason for x ## ll. It should match int32_t as long int indeed.
Also, nowhere on Xtensa code we use the INT32_C macro, so issue went unnoticed.
What do you think @xiaoxiang781216 ?

[xiaoxiang781216]

Interesting. Seems like a mistake, as I can't recall the reason for x ## ll. It should match int32_t as long int indeed. Also, nowhere on Xtensa code we use the INT32_C macro, so issue went unnoticed. What do you think @xiaoxiang781216 ?

@fdcavalcanti https://github.com/apache/nuttx/pull/16022/changes#diff-c4a8dc00d035c3341c541ec2b5c8b6ed3c00a89de8732e478af6d9943275a8bcR113 is typo? we should change ll to l,

[fdcavalcanti]

Seems like a typo to me. Will create PR.