jspaith
commented
6 years ago I'm able to reproduce this issue. Even though a fair amount has changed in the last 2 years internally, I apologize that you've had to bump into this.
My first question is whether you need to put 89 (and growing) parameters into a flat structure like this? I verified on gcc 5.4 / Ubuntu 16.04 that the below compiles:
DECLARE_MODEL(innerData1,
WITH_DATA(ascii_char_ptr, DeviceId1),
WITH_DATA(ascii_char_ptr, DeviceId2),
[many fields]
)
DECLARE_MODEL(innerData2,
WITH_DATA(ascii_char_ptr, DeviceId1),
[many fields]
)
DECLARE_MODEL(ContosoAnemometer,
WITH_DATA(ascii_char_ptr, DeviceId),
WITH_DATA(innerData1, inner_Data1),
WITH_DATA(innerData2, inner_Data2),
[many fields]
)The sum of all the fields for my test was well over 100, we only hit issue on macro expansion on an individual model being > 61.
I understand you may have back-compat concerns with existing JSON, but separating this out would get you unblocked and going right away and not bumping into preprocessor limits.
The 127 limit was introduced because Visual Studio can't handle more than this in its preprocessor. I'm not that familiar with the internals (I can learn more as needed) but in c-utility\tools\macro_utils_h_generator\macro_utils.tt there's fields called nArithmetic and nMacroParameters which specify the maximums of INC/DEC and the arg counts, respectively. (We set 124 and not 127 because we need 1st 3 fields for our own book-keeping.) You should be able to rebuild this project with higher maximums.
But... if segmenting the fields into sub-structures works for your JSON, I'd strongly recommend trying that approach 1st.
mredd
When updating from the 2015-11-30 pre-release to the current version, I discovered that our model is too big for the serializer. By current version, I refer to 2017-11-03, 2017-10-20, and 2016-10-14 (for testing purposes).
As of today, the model we're using has one
WITH_ACTIONitem and 89WITH_DATAitems. It compiled fine with the 2015-11-30 release, but it crashes on the current version. I haven't figured out yet why this happens now and why it didn't happen in the 2015-11-30 release, because theCOUNT_ARGimplementation (which I think is the critical factor) seems to be the same.However, this is a really annoying bug, because our model hasn't even grown to the final size yet and we would like to upgrade and stay on top of the development.
OS and version used:
SDK version used:
Description of the issue:
There are multiple issues. First, the
INC(x)andDEC(x)macros are not implemented high enough. Right now, only implementations up toINC1024andDEC1024are available. Extend this up to i.e.INC1600andDEC1600, respectively.When all INC and DEC steps can be performed, the preprocessor runs into other errors like
FOR_EACH_2_1not found, which does not make sense, becauseFOR_EACH_2(...)shall only expand to even suffixes. My observation is, that the implementation ofCOUNT_ARG(...)reaches the limit of max. 127 parameters for a macro definition (refer to C standard, chapter 5.2.4.1). Some compilers allow for longer parameter lists, but they are not required. This might explain the slightly different behavior in clang and gcc.Code sample exhibiting the issue:
Console log of the issue:
Here is the compile output when compiling above source sample as
iot-bug.c. The INC and DEC macros were already extended inmacro_utils.h.