why uint8_t instead of char for strings?

[Michiel van Leeuwen]

Posted on January 06, 2017 at 12:42

Why does the generated code from STM32CubeMX use uint8_t for strings, instead of the C standard char? The problem is that they differ in signedness, so gcc gives a warning. It's quite a pain, to be honest.

I can see this at least in the usb cdc class code, for example:

void USBD_GetString(uint8_t *desc, uint8_t *unicode, uint16_t *len)

That expects a string as 'desc', but uses uint8_t instead of char.,

[Jeroen3]

Posted on January 06, 2017 at 15:14

Char is an ambiguous type since it's width and signedness are not guardanteed. The sign can be changed in the compiler flags, and the width is not fixed in the standard. It's better to use explicit types.

CTRL-F replace char by uint8_t.

[Michiel van Leeuwen]

Posted on January 10, 2017 at 08:18

The most common (as far as I know) is that char is signed. The width might differ, I have worked on a platform where it was 16 bits. That platform has a smallest addressable unit of 16 bits. According to

https://en.wikipedia.org/wiki/C_data_types

 , the char on such a platform has be 16 bits.

It must be, otherwise, you can't read the second character.

So I still think that using char is a better choice here.

I can ofcourse replace that in the code, but it will be changed back whenever I need to re-generate the code in STM32CubeMX. So I'm not going that route.