C23 Bit-precise integer types
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf) allow
programmers to explicitly state their intent on how many bits are
needed; but since they are addressable, they need padding bits when
their width is not a multiple of CHAR_WIDTH. Some implementations might
use more padding for alignment. Where there is a need to save memory,
they are thus not suitable. Using bit-precise integer types in
bit-fields solves this issue.

So, I'd like to see bit-fields of bit-precise integer types in C:

http://www.colecovision.eu/stuff/proposal-bit-precise-bit-fields.html

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

> C23 Bit-precise integer types
> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf) allow
> programmers to explicitly state their intent on how many bits are
> needed; but since they are addressable, they need padding bits when
> their width is not a multiple of CHAR_WIDTH. Some implementations
> might use more padding for alignment. Where there is a need to save
> memory, they are thus not suitable. Using bit-precise integer types in
> bit-fields solves this issue.
>
> So, I'd like to see bit-fields of bit-precise integer types in C:
>
> http://www.colecovision.eu/stuff/proposal-bit-precise-bit-fields.html

I assume you are looking for feedback. I have some comments that
may sound harsh but they are not meant to be insulting. My
remarks are only about the proposal, and not about the author.

The proposal is terrible. It's poorly written, incomplete, not
fully thought out, confused, and insufficiently general. What is
being proposed (assuming my guesses are right about what that is)
offers nothing in the way of new expressive power and looks like
it will tend to be error prone in application.

Writing: start with a statement of new language constructs.
Give examples. When describing changes to the C standard, start
with an informal description of all the relevant changes, and
only afterwards give a list of specific changes to text in the
standard. Any justifications should be in a separate section
and after all description of what is being proposed. If there
needs to be a reference to some earlier submission such as N2774,
there should be a separate summary of what they say; don't make
the reader have to go looking for them.

The key element in the proposal is about a new kind of integer
type, but that isn't obvious, and furthermore really has nothing
to do with bitfields. The ramifications of introducing these
new types is enormous, and that is glossed over or ignored by
the proposal.

Minor point, but a significant one: the term "bit-precise" is an
awful choice of words. "Specified-width" is better, for example,
although others may be even better. Words are important, so an
effort should be made to find a suitably descriptive phrase.

There is more to say but I think these are the high order bits and
enough to get a conversation started, if you want to pursue it.

On 17/01/2022 18:51, Tim Rentsch wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>
>> C23 Bit-precise integer types
>> (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf) allow
>> programmers to explicitly state their intent on how many bits are
>> needed; but since they are addressable, they need padding bits when
>> their width is not a multiple of CHAR_WIDTH. Some implementations
>> might use more padding for alignment. Where there is a need to save
>> memory, they are thus not suitable. Using bit-precise integer types in
>> bit-fields solves this issue.
>>
>> So, I'd like to see bit-fields of bit-precise integer types in C:
>>
>> http://www.colecovision.eu/stuff/proposal-bit-precise-bit-fields.html
>
> I assume you are looking for feedback. I have some comments that
> may sound harsh but they are not meant to be insulting. My
> remarks are only about the proposal, and not about the author.
>
> The proposal is terrible. It's poorly written, incomplete, not
> fully thought out, confused, and insufficiently general. What is
> being proposed (assuming my guesses are right about what that is)
> offers nothing in the way of new expressive power and looks like
> it will tend to be error prone in application.
>
> Writing: start with a statement of new language constructs.
> Give examples. When describing changes to the C standard, start
> with an informal description of all the relevant changes, and
> only afterwards give a list of specific changes to text in the
> standard. Any justifications should be in a separate section
> and after all description of what is being proposed. If there
> needs to be a reference to some earlier submission such as N2774,
> there should be a separate summary of what they say; don't make
> the reader have to go looking for them.
>
> The key element in the proposal is about a new kind of integer
> type, but that isn't obvious, and furthermore really has nothing
> to do with bitfields. The ramifications of introducing these
> new types is enormous, and that is glossed over or ignored by
> the proposal.
>
> Minor point, but a significant one: the term "bit-precise" is an
> awful choice of words. "Specified-width" is better, for example,
> although others may be even better. Words are important, so an
> effort should be made to find a suitably descriptive phrase.
>
> There is more to say but I think these are the high order bits and
> enough to get a conversation started, if you want to pursue it.
>

It looks like you missed the point of the proposal. It is building on
n2763, which introduces bit-precise integer types to C. It is not
adding any new integer types, but merely requiring an existing (in C +
n2763) type to be supported in bitfields. It is a minor feature, which
could perhaps have been added to n2763 rather than having a separate
proposal. It seems quite an obvious and appropriate addition.

You might think the term "bit-precise" is an awful choice of words, but
it is apparently what the committee picked during discussions of earlier
versions of n2763.

As far as I know, n2763 has been viewed positively by the committee, and
is implemented (at least approximately) in clang, but is not yet part of
the draft standard.

(As for being "insufficiently general", I would really like to see the
standard require bitfield support for all integer types and enumerated
types - in my experience, bitfields of types such as uint16_t are very
useful and fully supported by most compilers. But that would be a
different proposal.)