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 B89C53858D37 for ; Mon, 23 Oct 2023 11:53:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B89C53858D37 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 B89C53858D37 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=1698062010; cv=none; b=benC3Z4utQiikQy/alFoY+5KktN+N5bJk9RJuuHeIgOU1nudNcJoNEJjvhBTpNkyLx/KbMgtci1guGtOmTYxjmvIQRPmzOtRkH54YJZfFeq4+nFTGh4g7xO9PE+di5dgS4BRwVp7U2qqWQuhS6ktI/j8dpyDk4fCoadSviUN5wE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698062010; c=relaxed/simple; bh=6agpNEHNBBijR9FRk7l36zgSu3mep22zPS929X80OnE=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Smtpl698f06XP/zrU+nC/owhC9DxoeeGaKw+OX39SgKbTlKPnh/0VCbnzBb1KRSKDwbdWq+x80zahYXHSNnSydHXdJ2JSiOBm30lCjy5HAGkD45S+kWdzDZ8Y6mEKyytv0m5d22W+cidf4nqj+bEFBnbV9RH4YF5tQ5d9UAzh6A= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698062007; 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=oTwIkyOmXgCoPHgHkcCmzIJwOqAE+NNAZz8sheYpxog=; b=Uwx6eyBRaGo2v3ggQd+C978RYRuGdB4w9rMzh1uFLiA84UDdCGF8dEOKm0M6taKOWABRgu foLzselGJ/HT5t13qxGNblXfp+dToUWjKyqbPmica6mzhLEdvNYkuykIcmH7syJaAFvLFI 9DI6Tbu1iJGSICQdoK9ZBUM1gv9EjVA= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-609-bLtHFJexNFKCFwPIdjkliw-1; Mon, 23 Oct 2023 07:53:26 -0400 X-MC-Unique: bLtHFJexNFKCFwPIdjkliw-1 Received: by mail-yb1-f200.google.com with SMTP id 3f1490d57ef6-d9a5836ab12so3843707276.2 for ; Mon, 23 Oct 2023 04:53:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698062006; x=1698666806; 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=oTwIkyOmXgCoPHgHkcCmzIJwOqAE+NNAZz8sheYpxog=; b=ZmT+3UhG9SjQPKUi4DQscaAtSq3oNwfJc6M+Mz1Gksgh8IQSx5N/6JKBgmyXtJ11sX 7JYtCNAW8b2kMiyVQIF9Idn7S6J8AlvfC82bH7BTjOXGWhGbU5oDEcPNYHDlDmvGtEDq tKd35zQizYbSaJsE+837Udo0RiKKZI1ggW9SNaVcGRPnawOno8O/cSpe4y/igvP78BS8 LB/zT92l3UFRFPr4osEhBkf5D+0/LWSoA5tW2iuiVCxcKkdOp2ssx0yY8jlaRJdRqBAc 97IuS2j/lmanFTrFIR/PH5/jsKeqFfIDPePG/HMUbYGwaGnhe35hqNJ4FVPeLnkivHx9 f8+w== X-Gm-Message-State: AOJu0YzUbVWAtYeXxYbZ502SCSxwResvKSU+CD7tFfAtVtRTfI/4avA0 /cWHWQkSREdLxe0ab4AKMqDDbvNqkjeujVqCvNVnddsRV3yBZIzsojeRNAWleGrkNf8Zch/j3Ug 9o34TeMeMupeSaeiadHoUExm0ku/3O6s= X-Received: by 2002:a25:d7c7:0:b0:d9a:4839:68fe with SMTP id o190-20020a25d7c7000000b00d9a483968femr7966073ybg.43.1698062005936; Mon, 23 Oct 2023 04:53:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEC5EIVyK8sX88kUbPYcM50K/cfFTKeeVcg0JSsbainfHUnqQaKKdvSPV2+b1oSVXYzDlWZ5CV12nOvc6u/xo8= X-Received: by 2002:a25:d7c7:0:b0:d9a:4839:68fe with SMTP id o190-20020a25d7c7000000b00d9a483968femr7966062ybg.43.1698062005705; Mon, 23 Oct 2023 04:53:25 -0700 (PDT) MIME-Version: 1.0 References: <32b868eb-2569-471c-8f19-aac7fc362c42@gmail.com> In-Reply-To: From: Jonathan Wakely Date: Mon, 23 Oct 2023 12:53:14 +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.2 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:45, Jonathan Wakely wrote: > > 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<< basicall= y > > prints it as a (u)char. I think this is very unfortunate and is somewha= t > > 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. P.S. the behaviour of printing signed char and unsigned char has been the same for 25 years, since the first C++ standard. Therefore the behaviour of printing int8_t and uint8_t has been the same for as long a those typedefs have existed (they were added to C99 in 1999, and then inherited by C++11 in 2011, but were already in common use before then). So this behaviour has been the same for a very long time. Plenty of users expect exactly what libstdc++ (and other implementations) do, because that's what it has always done. There are many things which are surprising to some people when they first encounter them. That doesn't mean we should or can change them now. Even if this were to change, it would have to happen in the C++ standard, not just in libstdc++. We implement the standard.