Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.std.c |
| Subject | Re: bit-fields of type unsigned long and unsigned long long |
| Date | 2021-06-25 08:09 -0700 |
| Organization | None to speak of |
| Message-ID | <875yy2ugks.fsf@nosuchdomain.example.com> (permalink) |
| References | (4 earlier) <sb2see$t4s$1@dont-email.me> <87v962vrh3.fsf@nosuchdomain.example.com> <sb44vv$frb$1@dont-email.me> <87a6neuxjo.fsf@nosuchdomain.example.com> <sb4g65$4m4$1@dont-email.me> |
David Brown <david.brown@hesbynett.no> writes:
> On 25/06/2021 11:02, Keith Thompson wrote:
>> I don't see an answer to my question anywhere in there.
>>
>> To be perhaps a bit clearer, when I compile this program with gcc or
>> clang:
>>
>> #include <stdio.h>
>> #include <limits.h>
>> int main(void) {
>> struct has_bit_field {
>> unsigned bit_field : 1;
>> };
>> struct has_unsigned_char {
>> unsigned char uc;
>> };
>> printf("CHAR_BIT = %d\n", CHAR_BIT);
>> printf("sizeof (unsigned) = %zu\n", sizeof (unsigned));
>> printf("sizeof (struct has_bit_field) = %zu\n", sizeof (struct has_bit_field));
>> printf("sizeof (struct has_unsigned_char) = %zu\n", sizeof (struct has_unsigned_char));
>> }
>>
>> the output on my system is:
>>
>> CHAR_BIT = 8
>> sizeof (unsigned) = 4
>> sizeof (struct has_bit_field) = 4
>> sizeof (struct has_unsigned_char) = 1
>>
>> What is the rationale for a bit-field forcing the structure to be
>> expanded to 4 bytes, when the bit-field itself is only 1 bit?
>> Why does a 1-bit bit-field for a bigger structure size than an 8-bit
>> unsigned char member?
>
> It lets the /programmer/ make the choice.
I really don't understand that statement.
The way I *wish* bit-fields had been implemented is that a bit-field has
the specified size, and its declared type has no effect on the
structure's layout. *That* would let the programmer make the choice,
for example by defining an umnamed bit-field for padding if desired.
With that scheme, I can define an 8-bit structure containing two 4-bit
bit-fields. With the current common implementation, I can't (unless I
use a non-standard type for the bit-fields).
A 1-bit bit-field doesn't have an alignment requirement. Why should it
impose such a requirement on the containing structure?
> When I write "uint16_t x : 3;", I mean "Make a container field of size
> and type uint16_t, and allocate 3 bits of it to x. If there is already
> a container field of this type and size with enough free space just
> before x, add it to the same container".
Sure, that's how it works -- but nothing in the standard gives a clue
that that's what it should mean.
It just seems bizarre to me that the type of a bit-field has no effect
on the representation of the bit-field itself (other than signedness),
but it does affect the representation of the containing structure.
> That is the function I want bit-fields to have. That is what makes them
> useful in a wide range of use-cases. There are some situations where
> all you need is to say "x doesn't have to hold more than 3 bits of
> information, and I'd like the surrounding structure to be reasonably
> small". But often you want to have the control.
How exactly does the current scheme give the programmer more control?
If I want extra padding, I can add it myself. If I don't, I get it
anyway.
> Another situation where you need precise control for hardware registers
> is in the access sizes for volatile data (and hardware registers are
> usually accessed as volatile). Access size typically makes a /huge/
> difference in the hardware. If the bit-field "x" above is part of a
> volatile structure, then all reads and writes to it must be done using
> 16-bit accesses. (gcc had a bug for a while in their ARM port that
> meant a smaller access size would be used for smaller bit size of
> fields, giving 8-bit accesses for a 3 bit bit-field regardless of the
> declared type. This caused a lot of problems.)
>
> All in all, I want the type I give in the bit-field declaration to be
> used by the compiler. Otherwise, what's the point of having it at all?
But why should the type of a bit-field affect the layout of the
containing struct but not the representation of the bit-field itself?
Why impose an arbitrary restriction?
[snip]
> And therein, perhaps, is the biggest problem with bit-fields in C.
> Because there is virtually no guidance in the standards in this respect,
> people with different experiences, practices and needs for the language
> can have widely different expectations or assumptions about them. (I
> expect that in actual code you would not make such assumptions, since I
> believe you often have to write more portable code that avoids relying
> on implementation-defined behaviour.)
The way it seems to me is that, yes, bit-fields are underspecified, but
the common implementation imposes an arbitrary restriction that reduces
the programmer's control. There's nothing you can do with the existing
scheme that couldn't be done with the one I would have preferred.
--
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 */
Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-22 16:49 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-22 17:18 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-22 11:17 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 08:25 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-23 08:59 +0200
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 13:12 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-23 14:14 +0200
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 17:45 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-23 10:22 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 19:52 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-23 16:12 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 10:41 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 10:32 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-23 00:39 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 13:22 +0200
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 18:27 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-23 10:53 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-23 20:13 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-24 11:48 -0700
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 12:23 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 22:40 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-10 09:13 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-24 22:14 +0200
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-10 09:23 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 11:02 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 11:06 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-24 23:11 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-24 15:16 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 10:43 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 02:02 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 13:54 +0200
Re: bit-fields of type unsigned long and unsigned long long Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-25 13:07 +0100
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 15:17 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 08:22 -0700
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 18:22 +0200
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 13:28 -0700
Re: bit-fields of type unsigned long and unsigned long long Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-06-25 19:12 +0100
Re: bit-fields of type unsigned long and unsigned long long Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-07-10 08:58 -0700
Re: bit-fields of type unsigned long and unsigned long long Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-25 08:09 -0700
Re: bit-fields of type unsigned long and unsigned long long Philipp Klaus Krause <pkk@spth.de> - 2021-06-25 14:43 +0200
Re: bit-fields of type unsigned long and unsigned long long David Brown <david.brown@hesbynett.no> - 2021-06-25 15:33 +0200
Re: bit-fields of type unsigned long and unsigned long long Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2021-07-06 23:18 +0200
csiph-web