Since bit-fields of type unsigned long and unsigned long long are
useful, commonly suppoted by implementations, and commonly used, I'd
like to see the standard support them.

Here's a draft of a proposal for that:

http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html

On 22/06/2021 16:49, Philipp Klaus Krause wrote:
> Since bit-fields of type unsigned long and unsigned long long are
> useful, commonly suppoted by implementations, and commonly used, I'd
> like to see the standard support them.

The standard /does/ support them - it simply does not mandate that an
implementation supports them. It's good to be accurate in your wording
for a proposal like that.

In my own code, I don't believe I have ever had need for types longer
than "unsigned int" in bitfields - though I have certainly used the type
"uint32_t" which happens to be "unsigned long" on several targets even
though "unsigned int" is the same size.

But I have a lot more use of smaller integer types. And I use
enumerated types in bitfields too, though these usually require a
minimum size matching "int" (unless you use compiler-specific extensions
to change that).

I would suggest that it is pointless to add to the list of types
mandated in the C standard here. Rather, it should simply say that a
bit-field shall have "an integer type". That covers all sizes, shorter
than int as well as longer, signed as well as unsigned. After all,
pretty much any serious modern C compiler will already support all
integer types here.

And I would also be even happier with "an integer type or enumerated type".

>
> Here's a draft of a proposal for that:
>
> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html
>

David Brown <david.brown@hesbynett.no> writes:
> On 22/06/2021 16:49, Philipp Klaus Krause wrote:
>> Since bit-fields of type unsigned long and unsigned long long are
>> useful, commonly suppoted by implementations, and commonly used, I'd
>> like to see the standard support them.
>
> The standard /does/ support them - it simply does not mandate that an
> implementation supports them. It's good to be accurate in your wording
> for a proposal like that.

In the proposal, I suggest:

This adds unsigned long and unsigned long long to the +required+
supported types for bit-fields.

> In my own code, I don't believe I have ever had need for types longer
> than "unsigned int" in bitfields - though I have certainly used the type
> "uint32_t" which happens to be "unsigned long" on several targets even
> though "unsigned int" is the same size.
>
> But I have a lot more use of smaller integer types. And I use
> enumerated types in bitfields too, though these usually require a
> minimum size matching "int" (unless you use compiler-specific extensions
> to change that).
>
> I would suggest that it is pointless to add to the list of types
> mandated in the C standard here. Rather, it should simply say that a
> bit-field shall have "an integer type". That covers all sizes, shorter
> than int as well as longer, signed as well as unsigned. After all,
> pretty much any serious modern C compiler will already support all
> integer types here.
>
> And I would also be even happier with "an integer type or enumerated type".

I agree. If you're going to mandate support for additional types, why
not go all the way?

Currently, plain int bit fields have implementation-defined signedness.
I'm not a big fan of that rule, but logically it should be extended to
bit fields of other integer types specified without a "signed" or
"unsigned" keyword -- except that a plain char bit field should IMHO
have the same signedness as plain char.

Signed bit fields are questionably useful, but support for them is
already required, and I'm sure there's code that depends on them.

>> Here's a draft of a proposal for that:
>>
>> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html

"support" is misspelled in the Justification section.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Am 22.06.21 um 20:17 schrieb Keith Thompson:
>>
>> But I have a lot more use of smaller integer types. And I use
>> enumerated types in bitfields too, though these usually require a
>> minimum size matching "int" (unless you use compiler-specific extensions
>> to change that).
>>
>> I would suggest that it is pointless to add to the list of types
>> mandated in the C standard here. Rather, it should simply say that a
>> bit-field shall have "an integer type". That covers all sizes, shorter
>> than int as well as longer, signed as well as unsigned. After all,
>> pretty much any serious modern C compiler will already support all
>> integer types here.
>>
>> And I would also be even happier with "an integer type or enumerated type".
>
> I agree. If you're going to mandate support for additional types, why
> not go all the way?

I am worried that support for types smaller than int¹ and signed types²
could be controversial. So I'm trying to go for the two types that seem
most useful, most used, and, I hope, least controversial.

¹ People might disagree on questions of type and promotion.
² People might disagree on signed / unsigned for plain types and on
support for 1-bit bit-fields.

Philipp

P.S.: Even today, people disagree on some questions on the type of
bit-fields. Even implementations do (e.g. GCC vs. clang). And some say
that the standard is intentionally ambiguous to make the type
essentially implementation-defined.

P.P.S.: Thanks to everyone for the comments on wording.

On 23/06/2021 08:25, Philipp Klaus Krause wrote:
> Am 22.06.21 um 20:17 schrieb Keith Thompson:
>>>
>>> But I have a lot more use of smaller integer types. And I use
>>> enumerated types in bitfields too, though these usually require a
>>> minimum size matching "int" (unless you use compiler-specific extensions
>>> to change that).
>>>
>>> I would suggest that it is pointless to add to the list of types
>>> mandated in the C standard here. Rather, it should simply say that a
>>> bit-field shall have "an integer type". That covers all sizes, shorter
>>> than int as well as longer, signed as well as unsigned. After all,
>>> pretty much any serious modern C compiler will already support all
>>> integer types here.
>>>
>>> And I would also be even happier with "an integer type or enumerated type".
>>
>> I agree. If you're going to mandate support for additional types, why
>> not go all the way?
>
> I am worried that support for types smaller than int¹ and signed types²
> could be controversial. So I'm trying to go for the two types that seem
> most useful, most used, and, I hope, least controversial.
>
> ¹ People might disagree on questions of type and promotion.
> ² People might disagree on signed / unsigned for plain types and on
> support for 1-bit bit-fields.
>
> Philipp
>
> P.S.: Even today, people disagree on some questions on the type of
> bit-fields. Even implementations do (e.g. GCC vs. clang). And some say
> that the standard is intentionally ambiguous to make the type
> essentially implementation-defined.
>
> P.P.S.: Thanks to everyone for the comments on wording.
>

I can appreciate your concerns about controversy. However, I suspect (I
have no statistics, surveys, reports or evidence beyond a few samples)
there are two groups of people who use bitfields:

1. Those that stick to standards-mandated and guaranteed portable types
(bool, signed int, unsigned int).

2. Those that use types supported by the single compiler they use, or by
most real compilers (whatever integer type they want).

Who is your proposal for? Who are you trying to help?

As it stands, it could help group 1 if they need longer unsigned types
in bitfields. But it won't do anything much for group 2, who already
use many different sizes (including smaller sizes). Group 2 programmers
outnumber group 1 programmers by orders of magnitude - relatively few C
programmers need to write fully portable C code restricted only to the
guarantees in the C standards, and those that do are unlikely to make
much use of bitfields because the specifications in the standards are so
weak.

If you follow my recommendation and mandate support for /all/ integer
types, then group 1 get significantly more flexibility and group 2 now
know that their code is more portable (though many details are still
implementation-dependent, at least they can expect the same results for
different compilers on the same target and ABI). It's not going to make
a big difference to anyone, but it would be nice to have the standard
reflect common usage.

I agree that your more limited proposal is more likely to get accepted
than a wider one. I simply don't think the limited version is worth the
effort - it needs to be wider to be of relevance in real code. So,
IMVHO (and I'm not the one making or submitting the proposal) it makes
sense to gamble for the big prize, and risk rejection for the more
controversial proposal.

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 22.06.21 um 20:17 schrieb Keith Thompson:
>>>
>>> But I have a lot more use of smaller integer types. And I use
>>> enumerated types in bitfields too, though these usually require a
>>> minimum size matching "int" (unless you use compiler-specific extensions
>>> to change that).
>>>
>>> I would suggest that it is pointless to add to the list of types
>>> mandated in the C standard here. Rather, it should simply say that a
>>> bit-field shall have "an integer type". That covers all sizes, shorter
>>> than int as well as longer, signed as well as unsigned. After all,
>>> pretty much any serious modern C compiler will already support all
>>> integer types here.
>>>
>>> And I would also be even happier with "an integer type or enumerated type".
>>
>> I agree. If you're going to mandate support for additional types, why
>> not go all the way?
>
> I am worried that support for types smaller than int¹ and signed types²
> could be controversial. So I'm trying to go for the two types that seem
> most useful, most used, and, I hope, least controversial.
>
> ¹ People might disagree on questions of type and promotion.
> ² People might disagree on signed / unsigned for plain types and on
> support for 1-bit bit-fields.
>
> Philipp
>
> P.S.: Even today, people disagree on some questions on the type of
> bit-fields. Even implementations do (e.g. GCC vs. clang). And some say
> that the standard is intentionally ambiguous to make the type
> essentially implementation-defined.
>
> P.P.S.: Thanks to everyone for the comments on wording.

Are there any implementations that support bit fields of types other
than the required ones that *don't* support them for all integer types?
I dislike arbitrary restrictions, especially if most implementations
won't impose those restrictions anyway. I wouldn't be surprised if all
implementations that support non-standard bit field types do so
consistently.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Am 23.06.21 um 08:59 schrieb David Brown:
>
> Who is your proposal for? Who are you trying to help?

Programmers that need bit-fields wider than 16 bits, and want them to be
(somewhat more) portable.

> If you follow my recommendation and mandate support for /all/ integer
> type

I think that goes too far. I don't want to mandate support for extended
integer types.

>
> I agree that your more limited proposal is more likely to get accepted
> than a wider one. I simply don't think the limited version is worth the
> effort - it needs to be wider to be of relevance in real code. So,
> IMVHO (and I'm not the one making or submitting the proposal) it makes
> sense to gamble for the big prize, and risk rejection for the more
> controversial proposal.
>

Some more far-reaching proposals on integers including bit-fields have
been rejected in the past.

I think I'll try to clean up my proposal for unsigned long and unsigned
long long, and add two questions at the end: "Does WG14 want to see a
proposal for further standard integer types along the lines of this
one?" and "Does WG14 want to see a proposal for bit-precise integer
types along the lines of this one?".

Philipp

Am 22.06.21 um 16:49 schrieb Philipp Klaus Krause:
> Since bit-fields of type unsigned long and unsigned long long are
> useful, commonly suppoted by implementations, and commonly used, I'd
> like to see the standard support them.
>
> Here's a draft of a proposal for that:
>
> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html
>

I now realize that in some way, the type question is even harder for
types wider than int than for types narrower than it. We already have
divergence on the type between GCC and clang for unsigned int
bit-fields. But there it only matters when you use _Generic (i.e. for
clang _Generic on an unsigned int bit-field will match unsigned int, but
for clang it won't).
For other uses, we have the integer promotions that work on anything
smaller than int. So x.b << z behaves similar on GCC vs clang, since x.b
is promoted to int (there is still the difference of promoting to int
vs. promoting to unsigned int).
But for an unsigned long bit-field x.b << z will often give a different
result on GCC vs clang: The topmost bits of the result might be 1 for
clang where they are 0 for GCC (as clang does the shift on an unsigned
long, while GCC does it on a type just as wide as the bit-field).

On 23/06/2021 13:12, Philipp Klaus Krause wrote:
> Am 23.06.21 um 08:59 schrieb David Brown:
>>
>> Who is your proposal for? Who are you trying to help?
>
> Programmers that need bit-fields wider than 16 bits, and want them to be
> (somewhat more) portable.
>
>> If you follow my recommendation and mandate support for /all/ integer
>> type
>
> I think that goes too far. I don't want to mandate support for extended
> integer types.
>

Given that no compiler (to my knowledge - and I'd be very interested in
counter-examples) actually has extended integer types, that is surely
not a problem.

>>
>> I agree that your more limited proposal is more likely to get accepted
>> than a wider one. I simply don't think the limited version is worth the
>> effort - it needs to be wider to be of relevance in real code. So,
>> IMVHO (and I'm not the one making or submitting the proposal) it makes
>> sense to gamble for the big prize, and risk rejection for the more
>> controversial proposal.
>>
>
> Some more far-reaching proposals on integers including bit-fields have
> been rejected in the past.
>
> I think I'll try to clean up my proposal for unsigned long and unsigned
> long long, and add two questions at the end: "Does WG14 want to see a
> proposal for further standard integer types along the lines of this
> one?" and "Does WG14 want to see a proposal for bit-precise integer
> types along the lines of this one?".
>

The bit-precise (<stdint.h>) integer types are all defined in terms of
integer types. (In theory, they could be extended integer types - in
practice, they are always standard integer types.) So your second
question here is superfluous.

The first question would be a reasonable compromise between your
original more limited proposal, and the wider one. I don't really know
how these proposals work, and how much they are all-or-nothing or for
questions and discussions, so you are in a better position to judge this
than I am.

> Given that no compiler (to my knowledge - and I'd be very interested in
> counter-examples) actually has extended integer types, that is surely
> not a problem.

I think they are mostly used in lesser-known compilers targeting
embedded systems; but AFAIK both GCC and clang have a 24-bit extended
integer type when targeting avr, also used as int24_t and uint24_t in
stdint.h.

>
> The bit-precise (<stdint.h>) integer types are all defined in terms of
> integer types. (In theory, they could be extended integer types - in
> practice, they are always standard integer types.) So your second
> question here is superfluous.

I meant the C23 bit-precise integer types from stdbitint.h, as per N2709.

>
> The first question would be a reasonable compromise between your
> original more limited proposal, and the wider one. I don't really know
> how these proposals work, and how much they are all-or-nothing or for
> questions and discussions, so you are in a better position to judge this
> than I am.
>

The proposal champion (usually an author, but can be someone else if no
author can attend the meeting) presents the proposal. Then there is a
discussion (with a time limit). Afterwards there usually are straw polls
on questions (usually suggested by the champion, but can be someone
else). Typical questions styles are "Does the comittee want <proposal>
for <next version of C standard>, as in Nxxxx?" (directly deciding) and
"Does the comittee want <proposal> along the lines of Nxxxx?" (to see
which direction to proceed, typically when the feeling from the
discussion is that the proposal needs further polishing, and the author
wants to know if it is worth doing so.

If you want to see some examples, have a look at the minutes fo a
meeting, e.g. N2691, though the words attributed to attendants there are
usually a summary of the stated position as perceived by the one writing
the minutes rather than the exact words (would be too long otherwise -
especially examples, references and arguments given to support the
position rarely appear in the minutes). Straw poll question wording and
results are AFAIK always exact though.

Am 23.06.21 um 13:22 schrieb Philipp Klaus Krause:

> For other uses, we have the integer promotions that work on anything
> smaller than int. So x.b << z behaves similar on GCC vs clang, since x.b
> is promoted to int (there is still the difference of promoting to int
> vs. promoting to unsigned int).

My mistake here: they always promote to int, as per 6.3.1.1 of the
latest standard draft N2596.

Philipp Klaus Krause <pkk@spth.de> writes:
>> Given that no compiler (to my knowledge - and I'd be very interested in
>> counter-examples) actually has extended integer types, that is surely
>> not a problem.
>
> I think they are mostly used in lesser-known compilers targeting
> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
> integer type when targeting avr, also used as int24_t and uint24_t in
> stdint.h.

gcc's documentation says "GCC does not support any extended integer types.".
I don't see anything about 24-bit integers.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Am 23.06.21 um 19:22 schrieb Keith Thompson:
> Philipp Klaus Krause <pkk@spth.de> writes:
>>> Given that no compiler (to my knowledge - and I'd be very interested in
>>> counter-examples) actually has extended integer types, that is surely
>>> not a problem.
>>
>> I think they are mostly used in lesser-known compilers targeting
>> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
>> integer type when targeting avr, also used as int24_t and uint24_t in
>> stdint.h.
>
> gcc's documentation says "GCC does not support any extended integer types.".
> I don't see anything about 24-bit integers.
>
> [...]
>

Hmm, https://gcc.gnu.org/wiki/avr-gcc mentions 24-bit integers. Maybe
they are 24-bit integers not considered extended integer types in the
sense of the standard? Though I don't know what they'd do that; AFAIK
that only makes sense if you want something that behaves like an integer
bigger than intmax_t.

Philipp Klaus Krause <pkk@spth.de> writes:

> Since bit-fields of type unsigned long and unsigned long long are
> useful, commonly suppoted by implementations, and commonly used, I'd
> like to see the standard support them.
>
> Here's a draft of a proposal for that:
>
> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html

Here is a possible (and simpler) alternative.

Type specifier for bit-fields is _Bool, int, signed, or unsigned
(with signed int and unsigned int being synonymous with signed
and unsigned, respectively).

Bit-fields of type _Bool act just like they do now.

Bit-fields of type int are either the same as an unsigned
bit-field or the same as a signed bit-field, with the choice
being implementation-defined, just like they are now.

Bit-fields of types signed and unsigned may use widths up to the
widths of intmax_t and uintmax_t, respectively.

The type of a signed bit-field is the first of signed, long,
long long, and intmax_t, that is wide enough to hold all the
possible values of the bit-field.

The type of an unsigned bit-field is the first of unsigned,
unsigned long, unsigned long long, and uintmax_t, that is wide
enough to hold all the possible values of the bit-field.

For compatibility with current integer promotion rules, an access
for an unsigned bit-field whose range of possible values are all
representable within the range of signed int yields a value that
has been promoted to type signed int, just like such things are
done now. In all other cases the type of a bit-field access
is the type of the bit-field, as stated above.

(Personally I like this approach better than allowing different
integer types as bit-field specifiers.)

Am 23.06.21 um 19:53 schrieb Tim Rentsch:
> Bit-fields of types signed and unsigned may use widths up to the
> widths of intmax_t and uintmax_t, respectively.
>

WG14 usually doesn't like to use the same syntax as C++ but with a
different meaning.
AFAIK, in C++, you can have an int bit-field wider than int (or whatever
else the type is), but the upper bits then are padding bits.

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 23.06.21 um 19:22 schrieb Keith Thompson:
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>>> Given that no compiler (to my knowledge - and I'd be very interested in
>>>> counter-examples) actually has extended integer types, that is surely
>>>> not a problem.
>>>
>>> I think they are mostly used in lesser-known compilers targeting
>>> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
>>> integer type when targeting avr, also used as int24_t and uint24_t in
>>> stdint.h.
>>
>> gcc's documentation says "GCC does not support any extended integer types.".
>> I don't see anything about 24-bit integers.
>>
>> [...]
>
> Hmm, https://gcc.gnu.org/wiki/avr-gcc mentions 24-bit integers. Maybe
> they are 24-bit integers not considered extended integer types in the
> sense of the standard? Though I don't know what they'd do that; AFAIK
> that only makes sense if you want something that behaves like an integer
> bigger than intmax_t.

Interesting. It does mention __int24 and __uint24 under "Extensions",
so apparently they're language extensions (allowed under 4p6) rather
than extended integer types. Perhaps they don't meet all the
requirements of (extended) integer types. Since the compiler appears
not to be fully conforming anyway, I'm not sure how much that matters
(except that it would have given us an example of extended integer types
in the wild).

Similarly, gcc supports __int128 and unsigned __int128 (note the
different syntax) as a language extension on some target systems.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 23/06/2021 17:45, Philipp Klaus Krause wrote:
>> Given that no compiler (to my knowledge - and I'd be very interested in
>> counter-examples) actually has extended integer types, that is surely
>> not a problem.
>
> I think they are mostly used in lesser-known compilers targeting
> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
> integer type when targeting avr, also used as int24_t and uint24_t in
> stdint.h.
>

I can't answer for clang. But gcc explicitly says it does not support
any extended integer types:
<https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html>

For the AVR (an 8-bit device, in case anyone reading is unfamiliar) it
/does/ support certain 24-bit types. In particular it supports 24-bit
pointers into a named address space "__memx", to handle generic pointers
as flash and ram are independent hardware address spaces on these
devices. However, "void *" is still 16-bit, and uintptr_t is still
16-bit. The 24-bit addresses are part of the named address extensions,
and not normal pointers.

And it supports a type "__int24" in the same manner as gcc on bigger
devices supports "__int128" - in most respects it works like an integer
type, but it specifically is /not/ an "extended integer type" (or an
"integer type") in C standards terms. And that means that there is /no/
int24_t or uint24_t in a standards compliant C library for the AVR with
gcc. You have to write "typedef __int24 int24_t;" yourself.

I would be surprised if clang is different from gcc here, but I have not
looked at it.

I don't know why gcc doesn't support 24-bit integers on the AVR as an
extended integer type - the prime reason it can't make __int128 into an
extended integer type on 64-bit systems is that it would need to change
the size of intmax_t, which would lead to all sorts of messes.

>>
>> The bit-precise (<stdint.h>) integer types are all defined in terms of
>> integer types. (In theory, they could be extended integer types - in
>> practice, they are always standard integer types.) So your second
>> question here is superfluous.
>
> I meant the C23 bit-precise integer types from stdbitint.h, as per N2709.
>

OK. These are new to me, and I think it would be worth expanding on
that a little (giving the reference as you have here). Now that I
understand it, I agree with that second question too.

>>
>> The first question would be a reasonable compromise between your
>> original more limited proposal, and the wider one. I don't really know
>> how these proposals work, and how much they are all-or-nothing or for
>> questions and discussions, so you are in a better position to judge this
>> than I am.
>>
>
> The proposal champion (usually an author, but can be someone else if no
> author can attend the meeting) presents the proposal. Then there is a
> discussion (with a time limit). Afterwards there usually are straw polls
> on questions (usually suggested by the champion, but can be someone
> else). Typical questions styles are "Does the comittee want <proposal>
> for <next version of C standard>, as in Nxxxx?" (directly deciding) and
> "Does the comittee want <proposal> along the lines of Nxxxx?" (to see
> which direction to proceed, typically when the feeling from the
> discussion is that the proposal needs further polishing, and the author
> wants to know if it is worth doing so.
>
> If you want to see some examples, have a look at the minutes fo a
> meeting, e.g. N2691, though the words attributed to attendants there are
> usually a summary of the stated position as perceived by the one writing
> the minutes rather than the exact words (would be too long otherwise -
> especially examples, references and arguments given to support the
> position rarely appear in the minutes). Straw poll question wording and
> results are AFAIK always exact though.
>

On 24/06/2021 01:12, Keith Thompson wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 23.06.21 um 19:22 schrieb Keith Thompson:
>>> Philipp Klaus Krause <pkk@spth.de> writes:
>>>>> Given that no compiler (to my knowledge - and I'd be very interested in
>>>>> counter-examples) actually has extended integer types, that is surely
>>>>> not a problem.
>>>>
>>>> I think they are mostly used in lesser-known compilers targeting
>>>> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
>>>> integer type when targeting avr, also used as int24_t and uint24_t in
>>>> stdint.h.
>>>
>>> gcc's documentation says "GCC does not support any extended integer types.".
>>> I don't see anything about 24-bit integers.
>>>
>>> [...]
>>
>> Hmm, https://gcc.gnu.org/wiki/avr-gcc mentions 24-bit integers. Maybe
>> they are 24-bit integers not considered extended integer types in the
>> sense of the standard? Though I don't know what they'd do that; AFAIK
>> that only makes sense if you want something that behaves like an integer
>> bigger than intmax_t.
>
> Interesting. It does mention __int24 and __uint24 under "Extensions",
> so apparently they're language extensions (allowed under 4p6) rather
> than extended integer types. Perhaps they don't meet all the
> requirements of (extended) integer types. Since the compiler appears
> not to be fully conforming anyway, I'm not sure how much that matters
> (except that it would have given us an example of extended integer types
> in the wild).
>

avr-gcc is very close to conforming (as freestanding rather than hosted)
these days, if you pick the right options (such as for 64-bit doubles).
It is obviously limited by the size of the target devices (it's not
easy to have 1023 members in a struct on a device that might have 256
bytes of ram!). And last I checked it was missing a few maths
functions, some wide character support, and a few other minor bits and
pieces. Still, full conformance is not particularly important to users
of such embedded tools.

> Similarly, gcc supports __int128 and unsigned __int128 (note the
> different syntax) as a language extension on some target systems.
>

On 23/06/2021 19:53, Tim Rentsch wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>
>> Since bit-fields of type unsigned long and unsigned long long are
>> useful, commonly suppoted by implementations, and commonly used, I'd
>> like to see the standard support them.
>>
>> Here's a draft of a proposal for that:
>>
>> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html
>
> Here is a possible (and simpler) alternative.
>
> Type specifier for bit-fields is _Bool, int, signed, or unsigned
> (with signed int and unsigned int being synonymous with signed
> and unsigned, respectively).
>
> Bit-fields of type _Bool act just like they do now.
>
> Bit-fields of type int are either the same as an unsigned
> bit-field or the same as a signed bit-field, with the choice
> being implementation-defined, just like they are now.
>
> Bit-fields of types signed and unsigned may use widths up to the
> widths of intmax_t and uintmax_t, respectively.
>
> The type of a signed bit-field is the first of signed, long,
> long long, and intmax_t, that is wide enough to hold all the
> possible values of the bit-field.
>
> The type of an unsigned bit-field is the first of unsigned,
> unsigned long, unsigned long long, and uintmax_t, that is wide
> enough to hold all the possible values of the bit-field.
>
> For compatibility with current integer promotion rules, an access
> for an unsigned bit-field whose range of possible values are all
> representable within the range of signed int yields a value that
> has been promoted to type signed int, just like such things are
> done now. In all other cases the type of a bit-field access
> is the type of the bit-field, as stated above.
>
> (Personally I like this approach better than allowing different
> integer types as bit-field specifiers.)
>

This would give a very different result from the way compilers implement
bitfields today. In particular, consider :

sizeof(struct { int8_t a : 1; });

today, that is 1 on compilers that accept any integer type in bit
fields. With your proposal, it would be sizeof(int).

sizeof(struct { int64_t a : 1; });

today, that is 8 (assuming 8-bit char), while with your proposal it
would be sizeof(int).

It would be conceivable that an implementation could make the types of
the bitfields act the way you describe, while keeping the sizes (and
alignments, padding, splitting, etc.) of the bitfields the same as
today. But it would be needlessly confusing, and lead to other
differences (such as when the bitfields are used in other expressions).
The only sane approach to bitfield types is that the type of the
bitfield is the type given by the programmer when they declared the
bitfield. (And here I agree with Keith that it is unfortunate that a
bitfield declared as type "int" might be signed or unsigned.)

I also note that your "simpler" alternative is significantly longer than
Philipp's original proposal or the even simpler, obvious, and currently
implemented change:

"A bit-field shall have a type that is a qualified or unqualified
version of an integer type".

That's what compilers do today, that's what programmers use today, and
it is shorter, simpler and clearer than any other version. And it is
consistent with C++ (which also allows enumeration types - which would
be another nice addition to the C standard).

David Brown <david.brown@hesbynett.no> writes:
> On 23/06/2021 19:53, Tim Rentsch wrote:
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>> Since bit-fields of type unsigned long and unsigned long long are
>>> useful, commonly suppoted by implementations, and commonly used, I'd
>>> like to see the standard support them.
>>>
>>> Here's a draft of a proposal for that:
>>>
>>> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html
>>
>> Here is a possible (and simpler) alternative.
>>
>> Type specifier for bit-fields is _Bool, int, signed, or unsigned
>> (with signed int and unsigned int being synonymous with signed
>> and unsigned, respectively).
>>
>> Bit-fields of type _Bool act just like they do now.
>>
>> Bit-fields of type int are either the same as an unsigned
>> bit-field or the same as a signed bit-field, with the choice
>> being implementation-defined, just like they are now.
>>
>> Bit-fields of types signed and unsigned may use widths up to the
>> widths of intmax_t and uintmax_t, respectively.
>>
>> The type of a signed bit-field is the first of signed, long,
>> long long, and intmax_t, that is wide enough to hold all the
>> possible values of the bit-field.
>>
>> The type of an unsigned bit-field is the first of unsigned,
>> unsigned long, unsigned long long, and uintmax_t, that is wide
>> enough to hold all the possible values of the bit-field.
>>
>> For compatibility with current integer promotion rules, an access
>> for an unsigned bit-field whose range of possible values are all
>> representable within the range of signed int yields a value that
>> has been promoted to type signed int, just like such things are
>> done now. In all other cases the type of a bit-field access
>> is the type of the bit-field, as stated above.
>>
>> (Personally I like this approach better than allowing different
>> integer types as bit-field specifiers.)
>
> This would give a very different result from the way compilers implement
> bitfields today. In particular, consider :
>
> sizeof(struct { int8_t a : 1; });
>
> today, that is 1 on compilers that accept any integer type in bit
> fields. With your proposal, it would be sizeof(int).

How does that follow? The bit field occupies only 1 bit. Why should
its underlying type affect the size of the structure?

I know that with gcc and clang, these structures have different sizes:
struct { _Bool bitfield:1; }
struct { unsigned bitfield:1; }
but I don't see anything in the standard that suggests they should.
(I vaguely recall that it's an ABI requirement.)

> sizeof(struct { int64_t a : 1; });
>
> today, that is 8 (assuming 8-bit char), while with your proposal it
> would be sizeof(int).
>
> It would be conceivable that an implementation could make the types of
> the bitfields act the way you describe, while keeping the sizes (and
> alignments, padding, splitting, etc.) of the bitfields the same as
> today. But it would be needlessly confusing, and lead to other
> differences (such as when the bitfields are used in other expressions).
> The only sane approach to bitfield types is that the type of the
> bitfield is the type given by the programmer when they declared the
> bitfield. (And here I agree with Keith that it is unfortunate that a
> bitfield declared as type "int" might be signed or unsigned.)

The "type of a bit-field" seems like a tricky concept. Consider:

struct { unsigned int bf: 1; };

N1570 6.7.2.1p5 says:
A bit-field shall have a type that is a qualified or unqualified
version of _Bool, signed int, unsigned int, or some other
implementation-defined type.
which implies that bf is of type unsigned int. But p10 says:
A bit-field is interpreted as having a signed or unsigned integer
type consisting of the specified number of bits.
So the type of bf is an unsigned type consisting of 1 bit, and clearly
that's not unsigned int.

I think p5 is referring to the type used to define the bit-field, and
p10 is referring to the (anonymous) type that the bit-field actually
ends up having. IMHO it could be worded more clearly.

> I also note that your "simpler" alternative is significantly longer than
> Philipp's original proposal or the even simpler, obvious, and currently
> implemented change:
>
> "A bit-field shall have a type that is a qualified or unqualified
> version of an integer type".
>
> That's what compilers do today, that's what programmers use today, and
> it is shorter, simpler and clearer than any other version. And it is
> consistent with C++ (which also allows enumeration types - which would
> be another nice addition to the C standard).

Any proposal should take C++ into account, both to steal ideas and to
avoid inconsistencies (like C++'s statement that if the specified width
is more than the width of the specified type, the extra bits are padding
bits).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Philipp Klaus Krause <pkk@spth.de> writes:

> Am 23.06.21 um 19:53 schrieb Tim Rentsch:
>
>> Bit-fields of types signed and unsigned may use widths up to the
>> widths of intmax_t and uintmax_t, respectively.
>
> WG14 usually doesn't like to use the same syntax as C++ but with a
> different meaning.
> AFAIK, in C++, you can have an int bit-field wider than int (or whatever
> else the type is), but the upper bits then are padding bits.

The obvious answer is to ask the C++ committee to change their
silly rule. And if they don't want to change it, just ignore it;
the C++ rule is already incompatible with C, now it will just be
incompatible in a different way. The gap between C and C++ has
increased to the point where they should be treated as separate
and independent languages.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 23.06.21 um 19:53 schrieb Tim Rentsch:
>>> Bit-fields of types signed and unsigned may use widths up to the
>>> widths of intmax_t and uintmax_t, respectively.
>>
>> WG14 usually doesn't like to use the same syntax as C++ but with a
>> different meaning.
>> AFAIK, in C++, you can have an int bit-field wider than int (or whatever
>> else the type is), but the upper bits then are padding bits.
>
> The obvious answer is to ask the C++ committee to change their
> silly rule. And if they don't want to change it, just ignore it;
> the C++ rule is already incompatible with C, now it will just be
> incompatible in a different way. The gap between C and C++ has
> increased to the point where they should be treated as separate
> and independent languages.

It's no more incompatible than any other C++ feature that doesn't exist
in C. A program that defines a bit field with a length that exceeds the
width of the type is a constraint violation in C, and valid in C++.

On the other hand, I agree that the C++ rule *seems* silly. I wonder
what the rationale is. (The earliest reference to the rule that I found
is in the C++ 1998 standard.)

It would be nice to avoid *gratuitous* incompatibilities between C and
C++.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Am 24.06.21 um 20:48 schrieb Tim Rentsch:
>
> The obvious answer is to ask the C++ committee to change their
> silly rule. And if they don't want to change it, just ignore it;
> the C++ rule is already incompatible with C, now it will just be
> incompatible in a different way. The gap between C and C++ has
> increased to the point where they should be treated as separate
> and independent languages.
>

WG14 and WG21 try to keep the common subset compatible, especially if it
is something that might appear in headers (for other code this matters
less - after all non-header source is usually either C or C++, but
headers are commonly shared).
And bit-fields are in struct declarations which are often in headers.

On 24/06/2021 21:23, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>> Am 23.06.21 um 19:53 schrieb Tim Rentsch:
>>>> Bit-fields of types signed and unsigned may use widths up to the
>>>> widths of intmax_t and uintmax_t, respectively.
>>>
>>> WG14 usually doesn't like to use the same syntax as C++ but with a
>>> different meaning.
>>> AFAIK, in C++, you can have an int bit-field wider than int (or whatever
>>> else the type is), but the upper bits then are padding bits.
>>
>> The obvious answer is to ask the C++ committee to change their
>> silly rule. And if they don't want to change it, just ignore it;
>> the C++ rule is already incompatible with C, now it will just be
>> incompatible in a different way. The gap between C and C++ has
>> increased to the point where they should be treated as separate
>> and independent languages.
>
> It's no more incompatible than any other C++ feature that doesn't exist
> in C. A program that defines a bit field with a length that exceeds the
> width of the type is a constraint violation in C, and valid in C++.
>
> On the other hand, I agree that the C++ rule *seems* silly. I wonder
> what the rationale is. (The earliest reference to the rule that I found
> is in the C++ 1998 standard.)
>
> It would be nice to avoid *gratuitous* incompatibilities between C and
> C++.
>

I'd be entirely happy with a rule in C and C++ that limited the size of
a bit-field to the size of the type - I agree it seems very strange that
C++ allows them to be bigger. But the other key difference in C++
bit-fields is that any integer type or enumeration type is allowed, and
that should (IMHO) be copied by the C standards.

On 24/06/2021 20:06, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 23/06/2021 19:53, Tim Rentsch wrote:
>>> Philipp Klaus Krause <pkk@spth.de> writes:
>>>> Since bit-fields of type unsigned long and unsigned long long are
>>>> useful, commonly suppoted by implementations, and commonly used, I'd
>>>> like to see the standard support them.
>>>>
>>>> Here's a draft of a proposal for that:
>>>>
>>>> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html
>>>
>>> Here is a possible (and simpler) alternative.
>>>
>>> Type specifier for bit-fields is _Bool, int, signed, or unsigned
>>> (with signed int and unsigned int being synonymous with signed
>>> and unsigned, respectively).
>>>
>>> Bit-fields of type _Bool act just like they do now.
>>>
>>> Bit-fields of type int are either the same as an unsigned
>>> bit-field or the same as a signed bit-field, with the choice
>>> being implementation-defined, just like they are now.
>>>
>>> Bit-fields of types signed and unsigned may use widths up to the
>>> widths of intmax_t and uintmax_t, respectively.
>>>
>>> The type of a signed bit-field is the first of signed, long,
>>> long long, and intmax_t, that is wide enough to hold all the
>>> possible values of the bit-field.
>>>
>>> The type of an unsigned bit-field is the first of unsigned,
>>> unsigned long, unsigned long long, and uintmax_t, that is wide
>>> enough to hold all the possible values of the bit-field.
>>>
>>> For compatibility with current integer promotion rules, an access
>>> for an unsigned bit-field whose range of possible values are all
>>> representable within the range of signed int yields a value that
>>> has been promoted to type signed int, just like such things are
>>> done now. In all other cases the type of a bit-field access
>>> is the type of the bit-field, as stated above.
>>>
>>> (Personally I like this approach better than allowing different
>>> integer types as bit-field specifiers.)
>>
>> This would give a very different result from the way compilers implement
>> bitfields today. In particular, consider :
>>
>> sizeof(struct { int8_t a : 1; });
>>
>> today, that is 1 on compilers that accept any integer type in bit
>> fields. With your proposal, it would be sizeof(int).
>
> How does that follow? The bit field occupies only 1 bit. Why should
> its underlying type affect the size of the structure?

The current practice is that the size (and alignment) of the struct or
its parts comes from the type used to declare the bit-field - just as
for any other field. As I said below, it would be conceivable for a
compiler to use the programmer's specified type to set the size of the
containing struct or addressable storage unit, while ignoring it for the
type of the field and how it is interpreted when used in an expression.
That would, however, seem arbitrary and counter-intuitive, as well as
being contrary to current practice and (if my interpretation is correct
- but I might be wrong here) to C++ standards.

>
> I know that with gcc and clang, these structures have different sizes:
> struct { _Bool bitfield:1; }
> struct { unsigned bitfield:1; }
> but I don't see anything in the standard that suggests they should.

I have used a few compilers that didn't support anything but "int"
(signed or unsigned) in bit-fields. (They were all C90 compilers, so no
_Bool.) I have never known a compiler that was happy with different
integer types for bit-fields and did anything other than have sizes that
come directly from the types specified for the bit-field. I can't claim
to have done extensive testing here, as it has not occurred to me that
they might do something different, but I regularly check that the sizes
of my structs are as expected. And for most of my work, there are
manufacturer-supplied headers defining structs and addresses for
accessing peripherals - they too regularly use bit-fields, and expect
the sizes to work rationally.

The standards, however, leave most such details as implementation
dependent. As you say, ABI's might be more specific.

> (I vaguely recall that it's an ABI requirement.)
>
>> sizeof(struct { int64_t a : 1; });
>>
>> today, that is 8 (assuming 8-bit char), while with your proposal it
>> would be sizeof(int).
>>
>> It would be conceivable that an implementation could make the types of
>> the bitfields act the way you describe, while keeping the sizes (and
>> alignments, padding, splitting, etc.) of the bitfields the same as
>> today. But it would be needlessly confusing, and lead to other
>> differences (such as when the bitfields are used in other expressions).
>> The only sane approach to bitfield types is that the type of the
>> bitfield is the type given by the programmer when they declared the
>> bitfield. (And here I agree with Keith that it is unfortunate that a
>> bitfield declared as type "int" might be signed or unsigned.)
>
> The "type of a bit-field" seems like a tricky concept. Consider:
>
> struct { unsigned int bf: 1; };
>
> N1570 6.7.2.1p5 says:
> A bit-field shall have a type that is a qualified or unqualified
> version of _Bool, signed int, unsigned int, or some other
> implementation-defined type.
> which implies that bf is of type unsigned int. But p10 says:
> A bit-field is interpreted as having a signed or unsigned integer
> type consisting of the specified number of bits.
> So the type of bf is an unsigned type consisting of 1 bit, and clearly
> that's not unsigned int.
>
> I think p5 is referring to the type used to define the bit-field, and
> p10 is referring to the (anonymous) type that the bit-field actually
> ends up having. IMHO it could be worded more clearly.

Indeed it could be clearer. The real type of the bit-field arguably
does not matter much, since you cannot take a pointer to the bit-field.
The most important aspect of its type is how it is treated in an
expression, as described in p10. The only way the type can be checked
directly is, I think, with _Generic - and gcc and clang consider the
bit-field width to be part of the type. But that is pretty obscure
usage. (In C++, the type might be used in other cases such as overloads
- and there the standards are explicit that the bit-field width is not
part of the type of the field, which seems simpler and clearer.)

>
>> I also note that your "simpler" alternative is significantly longer than
>> Philipp's original proposal or the even simpler, obvious, and currently
>> implemented change:
>>
>> "A bit-field shall have a type that is a qualified or unqualified
>> version of an integer type".
>>
>> That's what compilers do today, that's what programmers use today, and
>> it is shorter, simpler and clearer than any other version. And it is
>> consistent with C++ (which also allows enumeration types - which would
>> be another nice addition to the C standard).
>
> Any proposal should take C++ into account, both to steal ideas and to
> avoid inconsistencies (like C++'s statement that if the specified width
> is more than the width of the specified type, the extra bits are padding
> bits).
>

Agreed.