typedef unsigned char uint8;

I am new to the C game so forgive me if this sounds stupid.

I have seen this (typedef unsigned char uint8;) done several times an I don't understand why

I understand that by doing this you are basically making up your own type. And the "structure" you are making is an 8 bit structure that is unsigned ( I understand that) and is defined as a "char".

The standard "char" is already an 8 bit structure that by definition is unsigned. Why do this???

I also see "uint8" on a regular basis. I also understand this to be an unsigned 8 bit structure. Basically, it is a "byte". Again, why not use a "byte"?

Ken

I don't know why you would like your own type called uint8... I never do that anyway. There is already a build in type called uint8_t.

And no, char is not unsigned on the arduino. If you don't specify it a char is signed :slight_smile: (At least on the default Arduino platforms)

It allows you to use more intuitive datatypes through your code. Your example is not a big issue because I'm fairly sure an unsigned char is an unsigned char everywhere but if you code on multiple platforms, something like an int may be 16 bits or it may be 32 bits. Giving them explicit names means you can come back to it and know exactly what you're dealing with.

KenK:
The standard "char" is already an 8 bit structure that by definition is unsigned.

char is not unsigned. Nor is it signed. The standard allows either. char is not like int or long. In the Arduino world you can encounter either form of char.

If you (the programmer) want an unsigned 8 bit value then that is your responsibility.

septillion:
(At least on the default Arduino platforms)

I believe char is unsigned with the ARM compiler.

For what it's worth, there is a detailed discussion of char à la Arduino somewhere on this forum.

First, thanks for the input.

I just re-reviewed the Arduino reference manual and found that I had missed something in the definition of a "char". The manual states that the "char" is signed and has a range of -128 to 127. I missed that.

As far as the "int" goes, I understand the concept of cross platform examples. An "int" could be 16 bit, 32 bit or even 64 bit depending on the platform.

With respect to a "byte" is this structure an Arduino structure (not standard C)??

Again thanks for all of your inputs.

The learning curve is very steep.

Ken

KenK:
With respect to a "byte" is this structure an Arduino structure (not standard C)??

I believe it is. Funnily enough it is defined (in Arduino.h) as:
typedef uint8_t byte;

I see the use of typedef in 3rd party libraries causing conflicts. I'm sure there are appropriate uses for it but not wanting to type the "_t" on "uint8_t" is not one of them. It just leads to problems and makes the code harder to read.

With respect to a "byte" is this structure an Arduino structure (not standard C)??

Arduino specific. Well, also present in many other microcontroller and microprocessor oriented development environments, but NOT standardized.

None of the C normal types (char, short int, int, long, long long) have defined sizes. In fact; they specifically have UNdefined sizes. When it turned out that practical programming actually requires you to have data types with known numbers of bits, and that various environments were defining their own types (like "byte" and "halfword" and so on), the C standards people finally picked some names that everyone liked (or, more probably, everyone disliked less), and we got the uint8_t and similar. That was in the C99 standard; it takes a while for standards to get implemented in actual compilers, and become widely available (you still have to specify that you want C++11 in the avr-g++ compiler we're using.)

https://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h

Thanks for the input.

I have spend very little if any time looking over Arduino.h so I really don't know what is in there.

Since the structure "byte " is not a standard structure and is defined in Arduino.h, that explains why third part code often uses uint8_t.

Again Thanks for the input. It clears some things up.

Ken