2

In the below code snippet, why do we get an output of 600? Two questions will help me understand the behavior.

  1. I specified the type for variable b to be uint8_t, why doesn't the math operation restrict to the same type?
  2. I thought PRIu8 is the right type to print uint8_t, why isn't this working?

I was hoping to get the answer 88 which results from looping beyond the range of uint8_t

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

void main()
{

    uint8_t b = 200;
    printf("%" PRIu8 "\n",b+b+b);
    printf("%" PRIu8 "\n",3*b);

}

gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
niil87
  • 47
  • 5
  • There surely be a dupe, somewhere, but please read about [implicit conversions](https://en.cppreference.com/w/c/language/conversion), in particular integer promotion and the usual arithmetic conversions. If you want the result to be an `uint8_t`, you need a cast: https://godbolt.org/z/rjxejqrEb – Bob__ Apr 14 '23 at 22:03
  • This is due to default argument promotions. – Barmar Apr 14 '23 at 22:03
  • As mentioned by others, there are implicit conversions (e.g.) your `b` will be converted to `int` or `unsigned int`. You can get the expected result with: `printf("%u\n",(uint8_t) (b+b+b)); – Craig Estey Apr 14 '23 at 22:08
  • @Bob__ I searched for "default integer promotion printf", but couldn't find a good dupe for this. – Barmar Apr 14 '23 at 22:09
  • @niil87 MS Visual Studio outputs 88. – Vlad from Moscow Apr 14 '23 at 22:16
  • @Barmar Well, there's [this](https://stackoverflow.com/questions/65770931/promotions-and-conversions-of-variables-in-printf), which is close. – Bob__ Apr 14 '23 at 22:17
  • @Bob__ That's one of the ones I saw. I didn't think signed/unsigned was close enough to 8-bit/32-bit. – Barmar Apr 14 '23 at 22:18
  • BTW, it should be `int main(void)`. – Bob__ Apr 14 '23 at 22:24
  • @Bob__ Thank you for the feedback.. didn't realize this was important! https://stackoverflow.com/questions/8844915/what-happens-if-main-does-not-return-an-int-value – niil87 Apr 15 '23 at 00:26

3 Answers3

2

In my opinion it is a library bug.

In MS Visual Studio the macro PRIu8 is expanded to hhu as it should be and you get the expected result.

It is interesting to note that if to use clang then if you will write for example

printf("%" PRIu8 "\n",( uint8_t)(b+b+b));

when again you will get the expected result.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
2

In C, whenever you call a function with elipsis (...) arguments, such as printf, all of those arguments will undergo default argument promotions. This means that any smaller integer type will be converted to int and passed that way. So in printf, h type prefixes are irrelevant -- they'll be ignored by printf and have no effect (as the argument must be an int anyways).

In addition, the same conversion of smaller integer types will happen for any arithmetic operator (like + or *) and the resulting operation will be carried out with int precision, giving an int result.

To get the expected result, explicitly mask it to the appropriate size:

printf("%u\n", (b+b+b) & 0xff);
Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
0

If we take a look at inttypes.h, we find the following:

# define PRIu8      "u"

So this format specifier doesn't contain any length modifier. This makes sense in the context of its corresponding argument, as it's impossible to pass a uint8_t to a variadic function. Because this type has a smaller rank than int, a value of this type will get promoted to int. This promotion also happens in the expressions b+b+b and 3*b.

If you explicitly use a length modifier for a char, you'll get the expected result.

printf("%hhd\n",b+b+b);
printf("%hhd\n",3*b);
dbush
  • 205,898
  • 23
  • 218
  • 273