From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 583A73858D37 for ; Mon, 23 Oct 2023 11:45:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 583A73858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 583A73858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698061516; cv=none; b=rsUxNDYOS85Mj7jqq1Ntc/bAp8X9PII/1Hygaok1+1M/Rj3a85k3Sq86n8xIRxcHuMu5COkqQanYWif+VfxtpkAEuhg98//1yZNRo8k2bk/Dl7iPoC6NLXcX5juRmQVkLJWkHa1+2iveDeCHs1YwKTlRxmxQd8SUK8nxPCeZQGQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698061516; c=relaxed/simple; bh=Gsgd74ykosnWlaSfU8NYOW1AutkLLWiMAd3T3cI0r+M=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=pCseQFI5yBkK5hKcMSpVbmbYrV+in3nzvLS0C9Ey7Zo+LDEtlbWBpoEydR2KbvJxXye3rX162cIXmEvioxEJvvFKytjUWA2+Z+u+frn1M9Sx7JSsn0AmCNwgfopI2xy9l2w/lgvqc5hzeu6/wNohae6uJe3Jg3CNMpkKT/YdVdU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698061514; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WTaBEAwWpbtSRCUD7qqp0td8jB82rITDWucgr0qdECU=; b=ifr6000LnBu+ZHxqqSY9L1HDsXjiYyzPXv+kN/2dlN3tcNJnC6W9VoVTW8r07dUocmgqbA 3+8c3ipkg4eWjE7rBaHAbpb//ceH1iNd3wvorgSTPgUKWzhOPTNQ+el6lAfQjFZF8wOgBP x64JuNE+YhMoGWestsMwaTImrbz6JzQ= Received: from mail-yw1-f197.google.com (mail-yw1-f197.google.com [209.85.128.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-435-yyInganUM2aCrMHtXy_Y3A-1; Mon, 23 Oct 2023 07:45:13 -0400 X-MC-Unique: yyInganUM2aCrMHtXy_Y3A-1 Received: by mail-yw1-f197.google.com with SMTP id 00721157ae682-5a8ebc70d33so40258147b3.1 for ; Mon, 23 Oct 2023 04:45:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698061513; x=1698666313; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WTaBEAwWpbtSRCUD7qqp0td8jB82rITDWucgr0qdECU=; b=OPUjF/7FwiLnR9hzXPJyt8BQtN4YOPAw6zIoximALAz182P6iwI1fcN0SyWtWFuoVd zhL5U9m+V7Xh68UJNgDy5SrL2mRT7MBv6CZEzK5kQX6K8UWpst8yXjksKHb9LRunUje7 9Xj7OrjpVtdg0iFtR/Wf0leUoWJ1s8QCkptbJZseSRiHgoSkGERV4q91r662JtMK4fWx noYZZtGzx853FgEWGzxoT9sCXqiRs4n+zuWHOFfvmAMyBEeTjI9zFnaLcMA4e9STJwV/ chS69i1YsW9vM4qzADKFtSuH7LQVtqJlfZb7JzNdGl2dr3DWAc93p6YnOOq+b3nM5CL+ WDtw== X-Gm-Message-State: AOJu0Yzu++XpqfZExujoYi+84JeEFtcMQGMP4YJq084sP9bafrMysQM0 vFrO7GVgeiRbsJJKSvffIpNgBALt3uEVYXvD09xp7V5v6enIaQgazBwc7rFZ1TnwKKPHHNZI+o8 zspPAT7QyDbEa/2vviKE+gkP4sTuyuCI= X-Received: by 2002:a81:6c13:0:b0:59f:7fb9:621a with SMTP id h19-20020a816c13000000b0059f7fb9621amr8200467ywc.22.1698061512980; Mon, 23 Oct 2023 04:45:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IExyqihGGAhQa/hMVrzLAmTATQ0+dS2DUn+m8q+RwrCnJ5C8xp3aq+dVQJBVsCJ5DYcQrGkAv/pZ1ZmbWmpn/I= X-Received: by 2002:a81:6c13:0:b0:59f:7fb9:621a with SMTP id h19-20020a816c13000000b0059f7fb9621amr8200450ywc.22.1698061512650; Mon, 23 Oct 2023 04:45:12 -0700 (PDT) MIME-Version: 1.0 References: <32b868eb-2569-471c-8f19-aac7fc362c42@gmail.com> In-Reply-To: <32b868eb-2569-471c-8f19-aac7fc362c42@gmail.com> From: Jonathan Wakely Date: Mon, 23 Oct 2023 12:45:01 +0100 Message-ID: Subject: Re: operator<< and int8_t and uint8_t types.... To: =?UTF-8?Q?Th=C3=A9o_Papadopoulo?= Cc: "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 23 Oct 2023 at 12:36, Th=C3=A9o Papadopoulo = 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 > #include > > namespace std { > > std::ostream& operator<<(std::ostream& os,const int8_t v) { > return os << static_cast(v); > } > > std::ostream& operator<<(std::ostream& os,const uint8_t v) { > return os << static_cast(v); > } > } > > int main() { > std::int8_t a =3D 65; > std::uint8_t b =3D 66; > char c =3D '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 basic_ostream& operator<<(basic_ostream&, signed char); template basic_ostream& operator<<(basic_ostream&, 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>) would be a breaking change, and very surprising to all the users who do actually know how this works.