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


Groups > comp.std.c > #6424

Re: bit-precise bit-fields

Path csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.std.c
Subject Re: bit-precise bit-fields
Date Mon, 17 Jan 2022 09:51:42 -0800
Organization A noiseless patient Spider
Lines 48
Message-ID <86r196s11t.fsf@linuxsc.com> (permalink)
References <sr1dpq$bch$1@solani.org>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Injection-Info reader02.eternal-september.org; posting-host="15598caebf32ebbe97649a2f881af1fe"; logging-data="17642"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1IPQ7TuMfnlp+riHCKtDhLQDmxZOuMVs="
User-Agent Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock sha1:Vst86uuyAqUUHrSIEcoJnQX+cdE= sha1:QuJHGXmYz2OtVQbrOcAYHkQfKVE=
Xref csiph.com comp.std.c:6424

Show key headers only | View raw


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.

Back to comp.std.c | Previous | NextPrevious in thread | Next 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