Re: int8_t outputs char via <iostream>

[Jonathan Wakely <jwakely.gcc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

On Sat, 23 Dec 2023, 00:15 Olavi Esker via Gcc-help, <gcc-help@gcc.gnu.org>
wrote:

> Hello,
> With <iostream> int8_t prints out char according to ascii number. Similarly
> it reads a single char, which cannot be static converted. The compiler
> gives no warning whatsoever. But when <cstdio> is used with scanf %hhd and
> printf %d it works perfectly.


It's a bit misleading to say that printf %d works perfectly, when it does
an implicit cast to int which behaves exactly the same as using char with
%d.


Is this really the intended <iostream>
> functioning? In Rust i8



In Rust isn't it a distinct integral type, not just a typedef for a
character type? So not comparable.


and C <stdio.h> int8 works fine, too.
> #include <iostream>
> #include <cstdint>
>
> int main()
> {
> std::int8_t myInt{65};
> myInt += 1;
> std::cout << myInt;
> }
>
> Guess what this returns?
> Character "B".
>
> int main()
> {
> std::int8_t myInt{};
> std::cin >> myInt;
> std::cout << myInt;
> }
> This will also read a character, and
> print the characters ascii value.
> So if I give it 3, it read it as '3', and prints out 51.
>
>
> The compiler gives no warning of this whatsoever with the flags:
>                 "-std=c++20",
>                 "-pedantic-errors",
>                 "-Wall",
>                 "-Wpedantic",
>                 "-Wshadow",
>                 "-Wcast-align",
>                 "-Wlogical-op",
>                 "-Wno-unused-parameter",
>                 "-Weffc++",
>                 "-Wextra",
>                 "-Wconversion",
>                 "-Wsign-conversion".
>
>
> It does seem like a mistake to have `signed char` and `unsigned char`
> display as characters rather than numbers, since `char` is a distinct type.
> And so `char` could display as a character and the other two as integers.
>
> Wish you can change this, or at least have a warning, because <iostream>
> functions fine for higher bitted integers.
>
> Thanks.
> OE
>