Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.std.c |
| Subject | Re: bit-precise bit-fields |
| Date | 2022-01-17 09:51 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <86r196s11t.fsf@linuxsc.com> (permalink) |
| References | <sr1dpq$bch$1@solani.org> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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