Particle.variable() won't compile "int32_t" data type?

After updating to latest firmware 0.4.6 in ParticleDev, compiler complains about int32_t data type, but likes int

MAC OSX 10.10.5

Yup, that’s the highly protective/fuzzy/“annoying” mode.
I don’t think it’s the int32_t vs int but the const int vs. int. You may have use a cast.

But it could also be the unsigned vs. signed warning, “protecting” you from actually changing the numeric value (<-- Edit: That’s the reason)

not sure what you mean…

This won’t compile in the latest firmware, but did last version… so why?

int32_t myVar = 0;
void setup() 
  Particle.variable("myVar", &myVar, INT);

void loop() 


Try this

Particle.variable("myVar", (uint32_t*)&myVar, INT); // it was the unsigned vs. signed

I know it’s ugly, but it builds.

One of the reasons for the fuzzyness of the compiler is the fact that so many people wrote

char myString[64];
  Particle.variable("myVar", &myString, STRING);

This gets now checked too, and will reduce the noise about the ampersand &. I guess in future there will be more overloads for Particle.variable() that allow for multiple versions of int and also some new types.

but… without all the noise this builds:

int myVar = 0;  // <<<<<<<<<<<< 
void setup() 
  Particle.variable("myVar", &myVar, INT);

void loop() 


so it’s some kind of Particle compiler issue handling the data type alias?

because it does no good (and seems unnecessary) to have to cast your signed int to an unsigned…

Good point - worth an issue on GitHub :wink:

Some speculation, but talking for myself only, using int32_t vs. int is just a personal preference, since I come from times where int meant -32768…+32767 but now it does mean somthing else, but int16_t is still the same :wink:

The reason why the compiler gets so fuzzy with the more elaborate types is, that you explicitly state you definetly want 32bit and signed which is not 32bit and unsigned.
But if you use int you sort of only say give me some kind of huge number container :sunglasses:

1 Like

I think actually in standard C int really means "give me a signed integer of width at least equal to your platform’s width of a standard int" and int32_t means “give me an unsigned int exactly 32 bits wide” (i.e. portable).

I guess my naiveté is around my assumption that they are synonymous on a 32 bit platform…

you live… you learn

I vote for two new variable types to make it easy for those of us who are type challenged




Sure, you are right, but I more like the figurative approach :wink:

If you want the boring technical reason for it, it’s here

    static inline bool variable(const char *varKey, const uint8_t* userVar, const CloudVariableTypeString& userVarType);

    template<typename T> static inline bool variable(const char *varKey, const typename T::varref userVar, const T& userVarType);

    static inline bool variable(const char *varKey, const uint32_t* userVar, const CloudVariableTypeInt& userVarType);

These are the possible overloads for Particle.variable() and some target types can be matched without problem, others not.

Hi Everybody,

I think it is important to remember that on this particular platform, int and int32_t name the same type, but in general that is not true on every platform (like most Arduino’s for instance). So the overloaded compile-time checking code for Particle.variable follows the doc and allows int, and the compiler does not know that int and int32_t are the same.

As @ScruffR said, we could lobby to add an overload for int32_t if you need it, but moving the declaration to int is the best way forward.


sure, it is a trivial workaround.

I’ve just not previously come across an example where Particle has deprecated a data-type alias. The filtering added in this version, solving the problem of folks having problems mixing other data types with INT & STRING when using Particle.variable(), was the change, I suppose.

Yes, the change was stricter checks to avoid coding errors going silently undetected. I would have assumed int32_t to have worked, being an alias for int, but the source of truth is the API docs which specify to use an int.

We do work hard to ensure API changes are backwards compatible, but in this case we wanted to ensure users were following the API closely. I’ll add a note under the firmware updates thread.

1 Like

I hear a call to Python!

I came across a compiler issue today with 0.4.7 Firmware - I was trying to declare a Particle variable for a volatile int. This gave me a compiler error saying overloaded which until I read this thread I did not understand what it meant. The simple solution for me is to declare another variable as int and sync the two in loop(). Are there any other / more elegant ways of doing this? Thanks

I have not tried it with the new references (&) overloads, but usually type casting does sometimes help.

But if you post a code snippet, it’s a lot easier to see what you’re actually doing :wink: