From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Thu Jul 16 22:30:28 2026 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 946D5356DC8; Thu, 16 Jul 2026 22:30:28 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by www.open-std.org (Postfix) with ESMTP id 3F1AF356BCE for ; Thu, 16 Jul 2026 22:30:28 +0200 (CEST) Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5aea0fff535so4219513e87.3 for ; Thu, 16 Jul 2026 13:30:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784233827; cv=none; d=google.com; s=arc-20260327; b=PvCwAMp2VsZQDylS1zh8IbMG91Vtu68RWNknDLEILKfTIESYR90wfLWVqxv3poxeab feMbrka/IlU/QdYiJYYmuqm7hDtM3humce9xufvLESRh2SNFoxQw7we+pZt3zpOXast2 0lPGDBwSQkt/kaL27JMyG4/BcEDsE3yPjkrcQZjneC+76EAfRpyFMU86agFPVnbyQmJv th3GawQV7tV7BNL045dk+sMksTePmfKPcGzNjl483lVIv4PV+u9PvFaLwa7dcsSKh+03 EMjGLbYbIwSOI4AOr5JQQby51fGPgkhRby7jqeb2zs5jV6/vr3EnRC/urEczdWkbuyub ab9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kuSxJ8rZ7FKEspATwQoT69aburNPzZ4VWjS5tdkJzGk=; fh=YK4trsm8r2j9BOfSQzHdXVNnECj3dqLko+OZ+8yYEwU=; b=Q+PKVgKIl0p3pj88iutrC74ybU9DK6xxcVmS+1pK/8FWUZRTNFygcxygraxqJ1VTuC fNqmtiAPGBMDcNo+GZGhxrLo/GEPHb8gG8C503lpUgCUFqeuXua8BseEUzXG9ssDd8Xt +oiAczxokdL5XvThEje61RutAj+aKgQvMzlnix06X16aMLm+ADFc60RGx/C/JgQx0qqd DxmuCGmQnB4rwsIUwpv6tQfOua1oBiWGpBFzwI1J0ZSRd5kEDPR3JvFIPU6Tau062kKQ HfreBoXkq/q4SasVnE12r2RDLEib8y3N88xbNAAnUQHLqGiB4tfujQIXFHo5Qp4hLJyx /+cQ==; darn=open-std.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784233827; x=1784838627; darn=open-std.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kuSxJ8rZ7FKEspATwQoT69aburNPzZ4VWjS5tdkJzGk=; b=rBGB1Wo4iHPkDLgdAKLgsg4GgxgMEoWXhWdYI+Qe9+5A47pbQ0tjYDVKYTsegC2apL ByqiDhLwIja+AYBvVjVcNinmsfzrUlRd6rK3O6/IdyOQscVwB4kKaEEBLM/J3DzOtUXP 6Qjb0wkF4CssNZDrGfWXAt3AzLRJLOsYA10m37lR7UG2lxnpXS0Zg7WYc2CgeF90Tgl/ 6PEC/eOwTmrhmYjUB3NOUVoJJOM7/kbeSkRy9f5jDuCnkTL8HyzjGfzLXYVvMLza9Zrx tQvQsnbog5xpYceHAJZOm2tNyPuPw1EN1UbCFT2o7ok7Kp7gAx9UoqgRItzRd1paM9QQ 07qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784233827; x=1784838627; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=kuSxJ8rZ7FKEspATwQoT69aburNPzZ4VWjS5tdkJzGk=; b=JcsWkJJFmyEg2iNpobrvezh+KmsjRtlXKUNjVk0GCTqEggnvI3mk+tqX2lHaMJ/UKO djJ0LLIq9mIx9/EhRUBcNv8ElxhjjE+HMwJbr5IwXYo2t4lyDP58Hk03Dn9DXNq7U8ZO elnov7ew0aDIJMeXcTEh62ZTlDiONJcqc/8d9OIFnGoVLFn6Ns9DN17/W1v1SHwlTPCd odAYcLKLpmDpZSljuiOw1wK0aT4stbBQvXGLx++uyswDf8j8wGJQFkXKfa+P6wgYo23y Tr48MbUEAoAjjVctyzQgyHmiOl7SweF3QxIyCmpCmcYW+kHuWa+1nbbAFjSEJ0oPpvs3 hsnw== X-Gm-Message-State: AOJu0YykddH/4nY+d7Ogz9AXeM/WR8dZVmmgSm4wTZjq4DLimdX50b+T Bi9a30c3CFepGuqDq17xoukp1cEIGetY3gffva2z7vmHNj0UsvXeQL0mm2PLpepjxfSrd3iIPdm JBvygUt1GU+9BcEbTT6+Dr0FWALblQw8= X-Gm-Gg: AfdE7cnbFBcO64jwaCbnFgKyIF9V2FIELayoNFkgCGVXthsnyMuWkDlB2vP9coAQoYr lAOTkWGIgbgdL4b6BpI+W94swGN8PUYwFPSyVU2Od6JlG5PY0Rij5LTM+/Pdr6/ekRtLlLsiNfx IHJPHxwNED/zbyOHwcEZqiWyjCcGORYFBOMLIpMAUbNKX5XK4QJ3yLpu3WiWpn82ikSqdEgiFQV k8GukvneMALhKb6SjE2sbE4pXJ6kriBSi8xTQzWdPxcymd8OIaGNMkSifi1q4htm0mBHQ91v2dI kwGwpQVJny6S0dhxPg== X-Received: by 2002:ac2:5692:0:b0:5ae:c745:f39 with SMTP id 2adb3069b0e04-5b28dd94246mr111346e87.44.1784233827310; Thu, 16 Jul 2026 13:30:27 -0700 (PDT) MIME-Version: 1.0 References: <20260212213748.6704D356CEC@www.open-std.org> In-Reply-To: <20260212213748.6704D356CEC@www.open-std.org> From: Robert Seacord Date: Thu, 16 Jul 2026 16:30:16 -0400 X-Gm-Features: AUfX_mwohDn2g3-Lj1pQZrZ0za2JI3E2daA8Uyr_zRTOKHUSlgijO54wAPOt958 Message-ID: Subject: Re: [SC22WG14.35358] Integer promotions wording (issue 1021) To: Joseph Myers Cc: sc22wg14@open-std.org Content-Type: multipart/alternative; boundary="0000000000007921d90656c04f0e" Sender: owner-sc22wg14@open-std.org Precedence: bulk --0000000000007921d90656c04f0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think your formulation is a big improvement. However, parts of the first paragraph feel a bit squishy to me: The *integer promotions* are the following sequence of conversions, > applied to certain kinds of expressions where specified in their > respective subclauses. Each conversion is applied in turn if the type > resulting from the previous conversions satisfies the given conditions. Could we say something like this instead? Integer promotions are an ordered sequence of conversions applied as > specified by the subclauses of this standard. Each conversion in the sequence shall be applied only if its stated > conditions are satisfied by the type resulting from all prior conversions > in that sequence. There are other ways to write this, but I would like to avoid the phrase "certain kinds" as it sounds squishy. Thanks, rCs On Thu, Feb 12, 2026 at 4:37=E2=80=AFPM Joseph Myers = wrote: > Here is some proposed wording for issue 1021, making the integer > promotions convert all enumerations to their underlying type. > > The existing wording for integer promotions is awkward in that it has a > sentence about bit-precise bit-fields, relevant even to those wider than > int, in the middle of text that's otherwise about conversions to int or > unsigned int, so requiring "If the original type is not a bit-precise > integer type" in the following sentence. Rather than adding an extra > such exception about enumerated types, it seems clearer to rearrange the > description in the form of a sequence of conversions: > > > The *integer promotions* are the following sequence of conversions, > applied to certain kinds of expressions where specified in their > respective subclauses. Each conversion is applied in turn if the type > resulting from the previous conversions satisfies the given conditions. > > * If the expression has enumerated type, it is converted to the underlyin= g > type of the enumeration. > > * If the expression after the previous conversion is a bit-field of a > bit-precise integer type (6.2.5), it is converted to the corresponding > bit-precise integer type. [put existing footnote 50 here] > > * If the type resulting from the previous conversions is a bit-precise > integer type, no further conversions are applied as part of the integer > promotions. > > * If the expression after the previous conversions: > > - has an integer type (other than int or unsigned int) whose integer > conversion rank is less than or equal to the rank of int and unsigned > int; or > > - is a bit-field of type bool, int, signed int, or unsigned int > > then: > > - if an int can represent all values of the original type (as restricte= d > by the width, for a bit-field), the value is converted to an > int; > > - otherwise, it is converted to an unsigned int. > > All other types are unchanged by the integer promotions. > > (Keep the existing NOTE.) > > [Note: conversion from enumerations comes before conversion of bit-precis= e > bit-fields so that if bit-precise enums (N3705) are accepted and an > implementation allows bit-fields declared with such a type then the > integer promotions result in the declared bit-precise underlying type.] > > In 6.3.2.8 Usual arithmetic conversions, change "Otherwise, if any of the > two types is an enumeration, it is converted to its underlying type. Then= , > the integer promotions are performed on both operands." to "The integer > promotions are performed on both operands.". > > -- > Joseph S. Myers > josmyers@redhat.com > > --0000000000007921d90656c04f0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think your formulation is a big=C2=A0im= provement.=C2=A0 However, parts of the first paragraph feel a bit squishy t= o me:

The *integer= promotions* are the following sequence of conversions,
applied to certa= in kinds of expressions where specified in their
respective subclauses.= =C2=A0 Each conversion is applied in turn if the type
resulting from the= previous conversions satisfies the given conditions.

Could we say something like this instead?
<= br>
Integer promotions are= an ordered sequence of conversions applied as specified by the subclauses = of this standard.=C2=A0=
Each convers= ion in the sequence shall be applied only if its stated conditions are sati= sfied by the type resulting from all prior conversions in that sequence.

=C2=A0There are other ways to write this, but= I would like to avoid the phrase "certain kinds" as it sounds sq= uishy.

Thanks,
rCs

On Thu, Feb 12, 2026 at 4:37=E2=80=AFPM Joseph Myers <josmyers@redhat.com> wrote:
Here is some proposed wording= for issue 1021, making the integer
promotions convert all enumerations to their underlying type.

The existing wording for integer promotions is awkward in that it has a sentence about bit-precise bit-fields, relevant even to those wider than int, in the middle of text that's otherwise about conversions to int or=
unsigned int, so requiring "If the original type is not a bit-precise =
integer type" in the following sentence.=C2=A0 Rather than adding an e= xtra
such exception about enumerated types, it seems clearer to rearrange the description in the form of a sequence of conversions:


The *integer promotions* are the following sequence of conversions,
applied to certain kinds of expressions where specified in their
respective subclauses.=C2=A0 Each conversion is applied in turn if the type=
resulting from the previous conversions satisfies the given conditions.

* If the expression has enumerated type, it is converted to the underlying =
type of the enumeration.

* If the expression after the previous conversion is a bit-field of a
bit-precise integer type (6.2.5), it is converted to the corresponding
bit-precise integer type. [put existing footnote 50 here]

* If the type resulting from the previous conversions is a bit-precise
integer type, no further conversions are applied as part of the integer promotions.

* If the expression after the previous conversions:

=C2=A0 - has an integer type (other than int or unsigned int) whose integer=
=C2=A0 conversion rank is less than or equal to the rank of int and unsigne= d
=C2=A0 int; or

=C2=A0 - is a bit-field of type bool, int, signed int, or unsigned int

=C2=A0 then:

=C2=A0 - if an int can represent all values of the original type (as restri= cted
=C2=A0 by the width, for a bit-field), the value is converted to an
=C2=A0 int;

=C2=A0 - otherwise, it is converted to an unsigned int.

All other types are unchanged by the integer promotions.

(Keep the existing NOTE.)

[Note: conversion from enumerations comes before conversion of bit-precise =
bit-fields so that if bit-precise enums (N3705) are accepted and an
implementation allows bit-fields declared with such a type then the
integer promotions result in the declared bit-precise underlying type.]

In 6.3.2.8 Usual arithmetic conversions, change "Otherwise, if any of = the
two types is an enumeration, it is converted to its underlying type. Then, =
the integer promotions are performed on both operands." to "The i= nteger
promotions are performed on both operands.".

--
Joseph S. Myers
josmyers@redhat.co= m

--0000000000007921d90656c04f0e--