Re: operator<< and int8_t and uint8_t types....

[Jonathan Wakely <jwakely@redhat.com>]

On Mon, 23 Oct 2023 at 12:36, Théo Papadopoulo <papadopoulo@gmail.com> wrote:
>
>      Hi,
>
> I suspect that this will probably receive an answer "this is the
> intended/normal/expected  behavior",


Correct.

> but from what I saw on the internet
> this is a kind of gray area in the standard

Not really.

> and I did not found any
> (even closed) report on bugzilla, so I thought of asking here.
>
> Currently, printing a int8_t of uint8_t number with operator<< basically
> prints it as a (u)char. I think this is very unfortunate and is somewhat
> deceptive to
> users which expect a "int" like behavior.

But int8_t is not an int, it's a typedef for an unspecified 8-bit
integral type, typically signed char (or potentially, but unlikely,
char, if that happens to be signed). The behaviour when printing
signed char is 100% specfied, there is no wriggle room for doing
anything else.

> #include <iostream>
> #include <cstdint>
>
> namespace std {
>
>      std::ostream& operator<<(std::ostream& os,const int8_t v) {
>          return os << static_cast<int>(v);
>      }
>
>      std::ostream& operator<<(std::ostream& os,const uint8_t v) {
>          return os << static_cast<int>(v);
>      }
> }
>
> int main() {
>      std::int8_t a  = 65;
>      std::uint8_t b = 66;
>      char         c = 'c';
>      std::cerr << a << ' ' << b << ' ' << c << std::endl;
> }
>
> Without the operator<< overloads: this code prints:
>
> A B c
>
> whereas I think a programmer would expect to see:
>
> 65 66 c
>
> which is what is obtained with the overloads.
>
> There is an old and extended discussion on stack overflow on the
> subject, in which from some comment it seems that
> it is the promotion to int vs the conversion to char that plays a role
> here (and that gcc like many over compiler favors the char
> conversion over the int promotion, but I'm not so sure about the
> validity of this discussion).

The standard specifies exactly how integer promotions work. There is
nothing any compiler can do to favour one promotion or another, it's
dictated by the standard.

But that's irrelevant here, there is no promotion. The standard
requires the following overloads which define how signed char and
unsigned char are printed:

template<class traits>
basic_ostream<char, traits>& operator<<(basic_ostream<char, traits>&,
signed char);
template<class traits>
basic_ostream<char, traits>& operator<<(basic_ostream<char, traits>&,
unsigned char);

The standard requires int8_t and uint8_t to be typedefs, not distinct
types. On most platforms, there are no integral types with exactly 8
bits except for char, signed char and unsigned char, and since C++20,
char8_t. So int8_t and uint8_t MUST be typedefs for one of those. How
those are printed with iostreams is clearly specified by the standard.


> Certainly from the user's perspective, one would expect to see and
> integer value and not a char... and it does not look very difficult to do.

The standard already says how to print those types, adding a more
specialized overload that only works for std::ostream (and not
std::basic_ostream<char, acme::traits<char>>) would be a breaking
change, and very surprising to all the users who do actually know how
this works.