Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6426

Re: bit-precise bit-fields

Show all headers | View raw

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.)

Back to comp.std.c | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

bit-precise bit-fields Philipp Klaus Krause <pkk@spth.de> - 2022-01-04 13:15 +0100
  Re: bit-precise bit-fields Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 09:51 -0800
    Re: bit-precise bit-fields David Brown <david.brown@hesbynett.no> - 2022-01-17 20:03 +0100

csiph-web