From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Fri Aug 15 05:19:06 2025 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 D5531356BA6; Fri, 15 Aug 2025 05:19:06 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by www.open-std.org (Postfix) with ESMTP id 61DED356B82 for ; Fri, 15 Aug 2025 05:19:06 +0200 (CEST) Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-55ce521e3f4so1670026e87.1 for ; Thu, 14 Aug 2025 20:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755227945; x=1755832745; darn=open-std.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ciwe8RGFG77porQMquL9UgGoeni58A0oLMewUxK/o4E=; b=a9JhYqhwnhQfKVzooH/VdRNqQF6jVHNre91ypY9vdaKw8Yuu8JFVMuqU+zcBa+6PKz MI8cNxO6XFuLal5k1TVlIPPGEHrcHF1qthWtnfaDhLwYHrarhhYkMnZm3t2IZk4T1i8S IA7XKwbeNonvNUYR6yA49DmDSGe5G/qMX0YcA/hqVVrH6TjR9EKC+T8NIX+T8hYtrIzO yMlYTbMwATeOq2xLL3PAeMTo5IlGU8p9ekGS/umYfbcx8DYuSacpbmBFViLU8WONMAQ+ 9Y1TBM1xSlMsn2UZWvHsH83WoHhX7AV59TDaesAqEpM2rNufiKgjDcTNerPq6cK5zeRX kf0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755227945; x=1755832745; h=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=ciwe8RGFG77porQMquL9UgGoeni58A0oLMewUxK/o4E=; b=Uvz4rqUTkYQFogpVR86AKjLkrxX7Ms83eGuC9DDpqLy6U0lW9PqEpL5Ke13o5tfcmR MNC2qODJt/IJH45q3mk9k7Yz3VwONuCdY0LfO+/FEUA3hWHuwnKkI//EpahoEH24jOPM tOSg9Frh8xrJnL7R+DLUMadqpSNBae6v/aPJK9kHGs+ufyKvFxojcWrGk+BJsv9WTw8z sYI7cknFendOurTdge6hnnxHRwVYpmZv8SzVBxoYPUcAS4h3QoupGyUBdJX1oyi1WG3U bjpeRbtyNc9zBtyi/0yV65rZzJmzZHNym1goMPNXQLyl8DRsGqaBlSItzNuKlM0YiuCC ROEA== X-Gm-Message-State: AOJu0YxxIVErvTcbbsxRuqIzg6Q/NzxvgqR1k3NJ6kXknsImi+BB3VXr 8VUagGiVHo1qBmT5X2CRbljyIqS4kzwTEEskgURn1NHKYt+vb/J1klG0ZEJdxh7P7OabY1PkB9V vYY9IxxJmAbv9Sjj1n93RIMGJHZOyO2M= X-Gm-Gg: ASbGncvTBUoAjwOIr3JeFliUNSl5JrdnXS9/QP/zWUQn44hAx4/GlZAaf8I5K/uvFu1 XAXDjzGnkbXDRFY4PLI0BnAQr2LhvDGer3WcyTN7zMEUyKA1LFSHlCRzJ4VMc79MdpRgpv0MxwR uEa9dbWcs6r8oiVb6jX/X6pWGwRajWVO6tmgKMmVc2QRtou8flvEguFs1IjZ2EmHKm1UQxhP6h/ VkyLN6g6w4ae1iqpDzbjXjR X-Google-Smtp-Source: AGHT+IGuni3VCxjQkV1Vc1DnUx3ZbbJ4ezo85R9UEYeCihwDiR1b+yeQkAYEb9Ads582NPQk7QeXU2FuPbWUdi2ffaM= X-Received: by 2002:a05:6512:3c9f:b0:55c:e752:e9c6 with SMTP id 2adb3069b0e04-55ceea3fc3emr171822e87.10.1755227945077; Thu, 14 Aug 2025 20:19:05 -0700 (PDT) MIME-Version: 1.0 References: <20250311214713.2AF84356898@www.open-std.org> In-Reply-To: <20250311214713.2AF84356898@www.open-std.org> From: Robert Seacord Date: Thu, 14 Aug 2025 23:18:54 -0400 X-Gm-Features: Ac12FXzO_yHHJY36eYJ8qG4A_cs0aCje9wufJlr130Tsqqg9_L2ZwxJOMEztc7M Message-ID: Subject: Re: [SC22WG14.29650] New issue #1007: Implicitly unsigned bit-fields ambiguity To: Joseph Myers Cc: sc22wg14@open-std.org Content-Type: multipart/alternative; boundary="0000000000002a93e2063c5eda6e" Sender: owner-sc22wg14@open-std.org Precedence: bulk --0000000000002a93e2063c5eda6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm going to take a shot at answering these questions. These are not my final answers as I reserve the right to change my mind. > For C2Y, my preference would be to follow C++14 and remove the option for > bit-fields to be implicitly unsigned when the declared type is not unsign= ed I agree with this, but I guess I could change my mind if there is evidence this will break a lot of code. MISRA requires that "Bit fields should only be declared with explicitly signed or unsigned integer type" which should alleviate the issue for safety-related code bases. Question 1 Suppose the declared type of the bit-field is a typedef name defined in a > standard header and required to be a signed integer type. Must that type > also be signed as a bit-field, or might it be unsigned (for example, plai= n > int)? It must match the sign. Question 2 > > C11 introduced the rule that typedef names can be redefined with the same > type in the same scope. But what if the type is only the same outside of > bit-fields? Is the type of the bit-field considered explicitly signed whe= n > one definition uses signed and another does not? Yes, it should be considered explicitly signed Question 3 > Which of the above cases should be considered explicitly signed, and whic= h > should not? All ambiguous cases should be viewed as explicitly signed. Question 4 > > Does the rule about implementation-defined signedness include _BitInt? No Question 5 > > If the answer to Question 4 is "yes", does the constraint disallowing a > type _BitInt(1) apply before or after the reinterpretation as unsigned > for a bit-field? N/A On Tue, Mar 11, 2025 at 5:47=E2=80=AFPM Joseph Myers = wrote: > The following new C standard issue has been submitted. > > https://www.open-std.org/jtc1/sc22/wg14/issues/c23/issue1007.html > > ## Issue 1007: Implicitly unsigned bit-fields ambiguity > > Authors: Joseph Myers > Date: 2025-03-11 > Submitted against: C23 > Status: Open > Cross-references: [0315](issue:0315) > > There are several cases in which the rule that bit-fields declared > with types that are not explicitly `signed` or `unsigned` might be > treated as if either `signed` or `unsigned` had been specified leaves > ambiguity about exactly what is permitted. One such case dates back > to C90, and others have arisen over time as features have been added > to the standard (but they are all included together in this issue > report given how closely related they are). > > In C23, the rule is specified in 6.7.3.1 (Type specifiers): > > > Each of the comma-separated multisets designates the same type, > > except that for bit-fields, it is implementation-defined whether the > > specifier `int` designates the same type as `signed int` or the same > > type as `unsigned int`. > > Footnote 132, in 6.7.3.2 (Structure and union specifiers), explicitly > notes that such a type might be produced from a typedef name or typeof > specifiers: > > > As specified in 6.7.3, if the actual type specifier used is `int` or > > a typedef-name defined as `int`, then it is implementation-defined > > whether the bit-field is signed or unsigned. This includes an `int` > > type specifier produced using the typeof specifiers (6.7.3.6). > > (It's not entirely clear that this inclusion of typedef names is > adequately supported by the normative text, but that's not the subject > of this issue report.) > > The final response to [issue 0315](issue:0315) said the > implementation-defined signedness also applied for other > implementation-defined declared types such as `char`, `short`, `long` > and `long long`. > > No specific wording is suggested to address the questions here, as > direction from the committee is needed. For C2Y, my preference would > be to follow C++14 and remove the option for bit-fields to be > implicitly unsigned when the declared type is not unsigned, but that > would need a separate paper and not be appropriate to apply to C23 > (notwithstanding that [C++ core issue > 739](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739) > was considered a defect for C++). If that change were made for C2Y, > it might then be appropriate to declare most of these cases explicitly > unspecified for C23; if no such change is made for C2Y, further > consideration should be given to specifying some of these cases > explicitly. > > ### Question 1 > > Suppose the declared type of the bit-field is a typedef name defined > in a standard header and required to be a signed integer type. Must > that type also be signed as a bit-field, or might it be unsigned (for > example, plain `int`)? > > ```c > #include > #include > > struct s1 { > ptrdiff_t b1a : 20; > int32_t b1b : 20; > }; > ``` > > Although `ptrdiff_t` illustrates that this issue was present in C90, > it may be more likely to be encountered with types such as `int32_t`. > > If the option for bit-fields to be implicitly unsigned is not removed, > it might be appropriate to require typedefs in standard headers that > are required to be signed integer types to be signed as bit-field > types as well. > > ### Question 2 > > C11 introduced the rule that typedef names can be redefined with the > same type in the same scope. But what if the type is only the same > outside of bit-fields? Is the type of the bit-field considered > explicitly signed when one definition uses `signed` and another does > not? > > ```c > typedef int T; > typedef signed int T; > > struct s2 { > T b2 : 20; > }; > ``` > > ### Question 3 > > In some cases, it seems clear whether a type from the typeof > specifiers should be considered explicitly signed. For example, > typeof specifiers applied to a type name do not introduce any issues, > and if the typeof specifiers are applied to an expression referring to > a single declaration, or to a cast, it seems clear whether the > resulting type is explicitly signed. > > ```c > int i; > signed int si; > > struct s3a { > typeof (int) b3a : 20; // not explicitly signed > typeof (signed int) b3b : 20; // explicitly signed > typeof (i) b3c : 20; // not explicitly signed > typeof (si) b3d : 20; // explicitly signed > typeof ((int) si) b3e : 20; // not explicitly signed > typeof ((signed int) i) b3f : 20; // explicitly signed > }; > ``` > > In some other cases, it is less clear: where composite types are > involved, or usual arithmetic conversions, for example. > > ```c > int i; > signed int si; > extern int x; > extern signed int x; > > struct s3b { > typeof (x) b3g : 20; > typeof (i + si) b3h : 20; > }; > ``` > > In some further cases, the type appears to be specified as not > explicitly signed (and so potentially unsigned as a bit-field) because > the standard says `int` rather than `signed int`, but may not have > been considering this issue. > > ```c > signed short s; > > struct s3c { > typeof (+s) b3i : 20; // integer promotions convert signed short to int > typeof (s =3D=3D s) b3j : 20; // comparisons return int > typeof (0) b3k : 20; // this integer literal has type int > typeof (-1) b3l : 20; // negating an int literal leaves type int > }; > ``` > > Which of the above cases should be considered explicitly signed, and > which should not? > > ### Question 4 > > Does the rule about implementation-defined signedness include > `_BitInt`? > > ```c > struct s4 { > _BitInt (32) b4 : 20; // may this be unsigned? > }; > ``` > > I think there is a reasonable case to answer "no" to this question > based only on the current wording, on the basis that the response to > issue 0315 was only concerned with implementation-defined bit-field > types, and support for `_BitInt` types for bit-fields is not > implementation-defined. > > ### Question 5 > > If the answer to Question 4 is "yes", does the constraint disallowing > a type `_BitInt(1)` apply before or after the reinterpretation as > unsigned for a bit-field? > > ```c > struct s5 { > _BitInt (1) b5 : 1; // is this valid if _BitInt bit-fields are unsigned= ? > }; > ``` > > --0000000000002a93e2063c5eda6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm going to take a shot at answering these quest= ions.=C2=A0 These are not my final answers as I reserve the right to change= my mind.=C2=A0
=C2=A0
For C2Y, my preference would be to follow C++14 and remove the= option for bit-fields to be implicitly unsigned when the declared type is = not unsigned

I agree with this, but I guess I could change = my mind if there is evidence this will break a lot of code. =C2=A0
MISRA= requires that "Bit fields should only be declared with explicitly sig= ned or unsigned integer type" which should alleviate the issue for saf= ety-related code bases.

Question 1

Suppose t= he declared type of the bit-field is a typedef name defined in a standard h= eader and required to be a signed integer type. Must that type also be sign= ed as a bit-field, or might it be unsigned (for example, plain=C2=A0= int)?

It must match the sign.=C2= =A0=C2=A0

Question 2

C11 introduced the rule that typedef names can be redefined with the same = type in the same scope. But what if the type is only the same outside of bi= t-fields? Is the type of the bit-field considered explicitly signed when on= e definition uses=C2=A0signed=C2=A0and another does not?

Yes, it should be considered explicitly signed

Questi= on 3
Which of the above cases should be consider= ed explicitly signed, and which should not?
All ambiguous cases should be viewed as explicitly signed.

Question 4

D= oes the rule about implementation-defined signedness include _BitInt?

No

Question 5

If the answer to Question 4 is "yes", does = the constraint disallowing a type=C2=A0_BitInt(1)=C2=A0apply b= efore or after the reinterpretation as unsigned for a bit-field?

N/A=C2=A0

On Tue, Mar 11, 2025 at 5:47=E2=80=AFPM Joseph Myers <= josmyers@redhat.com> wrote:
The following new= C standard issue has been submitted.

https://www.open-std.org/jtc1/sc22/= wg14/issues/c23/issue1007.html

## Issue 1007: Implicitly unsigned bit-fields ambiguity

Authors: Joseph Myers=C2=A0
Date: 2025-03-11=C2=A0
Submitted against: C23=C2=A0
Status: Open=C2=A0
Cross-references: [0315](issue:0315)

There are several cases in which the rule that bit-fields declared
with types that are not explicitly `signed` or `unsigned` might be
treated as if either `signed` or `unsigned` had been specified leaves
ambiguity about exactly what is permitted.=C2=A0 One such case dates back to C90, and others have arisen over time as features have been added
to the standard (but they are all included together in this issue
report given how closely related they are).

In C23, the rule is specified in 6.7.3.1 (Type specifiers):

> Each of the comma-separated multisets designates the same type,
> except that for bit-fields, it is implementation-defined whether the > specifier `int` designates the same type as `signed int` or the same > type as `unsigned int`.

Footnote 132, in 6.7.3.2 (Structure and union specifiers), explicitly
notes that such a type might be produced from a typedef name or typeof
specifiers:

> As specified in 6.7.3, if the actual type specifier used is `int` or > a typedef-name defined as `int`, then it is implementation-defined
> whether the bit-field is signed or unsigned. This includes an `int` > type specifier produced using the typeof specifiers (6.7.3.6).

(It's not entirely clear that this inclusion of typedef names is
adequately supported by the normative text, but that's not the subject<= br> of this issue report.)

The final response to [issue 0315](issue:0315) said the
implementation-defined signedness also applied for other
implementation-defined declared types such as `char`, `short`, `long`
and `long long`.

No specific wording is suggested to address the questions here, as
direction from the committee is needed.=C2=A0 For C2Y, my preference would<= br> be to follow C++14 and remove the option for bit-fields to be
implicitly unsigned when the declared type is not unsigned, but that
would need a separate paper and not be appropriate to apply to C23
(notwithstanding that [C++ core issue
739](https://www.open-std.org/jtc1/= sc22/wg21/docs/cwg_defects.html#739)
was considered a defect for C++).=C2=A0 If that change were made for C2Y, it might then be appropriate to declare most of these cases explicitly
unspecified for C23; if no such change is made for C2Y, further
consideration should be given to specifying some of these cases
explicitly.

### Question 1

Suppose the declared type of the bit-field is a typedef name defined
in a standard header and required to be a signed integer type.=C2=A0 Must that type also be signed as a bit-field, or might it be unsigned (for
example, plain `int`)?

```c
#include <stddef.h>
#include <stdint.h>

struct s1 {
=C2=A0 ptrdiff_t b1a : 20;
=C2=A0 int32_t b1b : 20;
};
```

Although `ptrdiff_t` illustrates that this issue was present in C90,
it may be more likely to be encountered with types such as `int32_t`.

If the option for bit-fields to be implicitly unsigned is not removed,
it might be appropriate to require typedefs in standard headers that
are required to be signed integer types to be signed as bit-field
types as well.

### Question 2

C11 introduced the rule that typedef names can be redefined with the
same type in the same scope.=C2=A0 But what if the type is only the same outside of bit-fields?=C2=A0 Is the type of the bit-field considered
explicitly signed when one definition uses `signed` and another does
not?

```c
typedef int T;
typedef signed int T;

struct s2 {
=C2=A0 T b2 : 20;
};
```

### Question 3

In some cases, it seems clear whether a type from the typeof
specifiers should be considered explicitly signed.=C2=A0 For example,
typeof specifiers applied to a type name do not introduce any issues,
and if the typeof specifiers are applied to an expression referring to
a single declaration, or to a cast, it seems clear whether the
resulting type is explicitly signed.

```c
int i;
signed int si;

struct s3a {
=C2=A0 typeof (int) b3a : 20; // not explicitly signed
=C2=A0 typeof (signed int) b3b : 20; // explicitly signed
=C2=A0 typeof (i) b3c : 20; // not explicitly signed
=C2=A0 typeof (si) b3d : 20; // explicitly signed
=C2=A0 typeof ((int) si) b3e : 20; // not explicitly signed
=C2=A0 typeof ((signed int) i) b3f : 20; // explicitly signed
};
```

In some other cases, it is less clear: where composite types are
involved, or usual arithmetic conversions, for example.

```c
int i;
signed int si;
extern int x;
extern signed int x;

struct s3b {
=C2=A0 typeof (x) b3g : 20;
=C2=A0 typeof (i + si) b3h : 20;
};
```

In some further cases, the type appears to be specified as not
explicitly signed (and so potentially unsigned as a bit-field) because
the standard says `int` rather than `signed int`, but may not have
been considering this issue.

```c
signed short s;

struct s3c {
=C2=A0 typeof (+s) b3i : 20; // integer promotions convert signed short to = int
=C2=A0 typeof (s =3D=3D s) b3j : 20; // comparisons return int
=C2=A0 typeof (0) b3k : 20; // this integer literal has type int
=C2=A0 typeof (-1) b3l : 20; // negating an int literal leaves type int
};
```

Which of the above cases should be considered explicitly signed, and
which should not?

### Question 4

Does the rule about implementation-defined signedness include
`_BitInt`?

```c
struct s4 {
=C2=A0 _BitInt (32) b4 : 20; // may this be unsigned?
};
```

I think there is a reasonable case to answer "no" to this questio= n
based only on the current wording, on the basis that the response to
issue 0315 was only concerned with implementation-defined bit-field
types, and support for `_BitInt` types for bit-fields is not
implementation-defined.

### Question 5

If the answer to Question 4 is "yes", does the constraint disallo= wing
a type `_BitInt(1)` apply before or after the reinterpretation as
unsigned for a bit-field?

```c
struct s5 {
=C2=A0 _BitInt (1) b5 : 1; // is this valid if _BitInt bit-fields are unsig= ned?
};
```

--0000000000002a93e2063c5eda6e--