u32 Not Recognized

@Inq I just tried it with no problems, very weird.

Hi @inq & @zander ,

  For Arduino 1.8 ....

  In a 'default blank' sketch, inside loop(),  I concur with Ron that

  u32 fred;

seems to compile with Uno selected, but not ESP32

-----------

However ...

unit32_t bert;

compiles with either board type.

Just a suggestion ....

--------

For Arduino 2.0

Similar behaviour ... though compiler whinged about variables not being used!

Dave

@inq

I always use the uint32_t form which has always worked. Are you sure you have the identical board set up on your new machine?

If not then the u32 type labels may not be supported.

Ron B

Posted by: @davee

Hi @inq & @zander ,

  For Arduino 1.8 ....

  In a 'default blank' sketch, inside loop(),  I concur with Ron that

  u32 fred;

seems to compile with Uno selected, but not ESP32

-----------

However ...

unit32_t bert;

compiles with either board type.

Just a suggestion ....

--------

For Arduino 2.0

Similar behaviour ... though compiler whinged about variables not being used!

Dave

Oops... I should have mentioned, I'm using 1.8.19.  

Interesting note on 2.0... that is what Microsoft compilers will do.  A good sign for the 2.0 version.

Posted by: @ronbentley1

@inq

I always use the uint32_t form which has always worked. Are you sure you have the identical board set up on your new machine?

If not then the u32 type labels may not be supported.

Ron B

 

The only difference (that I know of) between the two machines... my main development machine has all the ESP8266/ESP32 setup on it.  The second machine only has the bare Arduino installation.  But both machines were compiling for an  Uno.

I've always used the smallest name length versions (s8, u8, s16, u16, s32, u32) in my libraries... now running around 50k lines of code.  Never noticed an issue before.

VBR,

Inq

Posted by: @inq

Compiling for an Arduino Uno, on my everyday computer this works as-is just fine.

u32 gonzo = 42;
void setup() {}
void loop() {}

On a fresh install, on a new machine, it fails... with unknown type error message.  Anyone got a possible reason why?

VBR,

Inq

The problem is that these are non standard ISO identifiers, and predate the ones defined in <stdint.h> and <cstdint>, therefore are not portable as you've found out. 

You should really be using the portable naming conventions as defined on those headers.

int32_t / uint32_t, etc...

Posted by: @inq

Posted by: @ronbentley1

@inq

I always use the uint32_t form which has always worked. Are you sure you have the identical board set up on your new machine?

If not then the u32 type labels may not be supported.

Ron B

 

The only difference (that I know of) between the two machines... my main development machine has all the ESP8266/ESP32 setup on it.  The second machine only has the bare Arduino installation.  But both machines were compiling for an  Uno.

I've always used the smallest name length versions (s8, u8, s16, u16, s32, u32) in my libraries... now running around 50k lines of code.  Never noticed an issue before.

VBR,

Inq

Arduino IDE's automatically includes <Arduino.h>.

Each of ESP8266, ESP32 and UNO all pull in a different version of <Arduino.h>.

UNO version #includes: <USBAPI.h> which defines u32 as: typedef unsigned long u32;

ESP8266 version #includes: <c_types.h> which defines u32 as: typedef unsigned int u32;

ESP32 version uses <cstdint> in which all the types are in the 'std' namespace, and u32 is not supported.

Now you can see how non portable these are.

@frogandtoad - Yes, I understand they pull in different versions of the Arduino.h  IF I am using different boards.  But as I'm saying when I am setting the environment to an Uno on both machines, they both should be including the exact same files.  Obviously, they aren't as the compiler doesn't recognize the type on one.

@frogandtoad 

Thanks, that makes sense, the devil is always in the detail!

Ron B