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

Groups > comp.std.c > #6223 > unrolled thread

bit-fields of type unsigned long and unsigned long long

Back to article view | Back to comp.std.c

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#6223 — bit-fields of type unsigned long and unsigned long long

Since bit-fields of type unsigned long and unsigned long long are
useful, commonly suppoted by implementations, and commonly used, I'd
like to see the standard support them.

Here's  a draft of a proposal for that:

http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html

[toc] | [next] | [standalone]

#6224

On 22/06/2021 16:49, Philipp Klaus Krause wrote:
> Since bit-fields of type unsigned long and unsigned long long are
> useful, commonly suppoted by implementations, and commonly used, I'd
> like to see the standard support them.

The standard /does/ support them - it simply does not mandate that an
implementation supports them.  It's good to be accurate in your wording
for a proposal like that.

In my own code, I don't believe I have ever had need for types longer
than "unsigned int" in bitfields - though I have certainly used the type
"uint32_t" which happens to be "unsigned long" on several targets even
though "unsigned int" is the same size.

But I have a lot more use of smaller integer types.  And I use
enumerated types in bitfields too, though these usually require a
minimum size matching "int" (unless you use compiler-specific extensions
to change that).


I would suggest that it is pointless to add to the list of types
mandated in the C standard here.  Rather, it should simply say that a
bit-field shall have "an integer type".  That covers all sizes, shorter
than int as well as longer, signed as well as unsigned.  After all,
pretty much any serious modern C compiler will already support all
integer types here.

And I would also be even happier with "an integer type or enumerated type".

> 
> Here's  a draft of a proposal for that:
> 
> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html
> 

[toc] | [prev] | [next] | [standalone]

#6225

David Brown <david.brown@hesbynett.no> writes:
> On 22/06/2021 16:49, Philipp Klaus Krause wrote:
>> Since bit-fields of type unsigned long and unsigned long long are
>> useful, commonly suppoted by implementations, and commonly used, I'd
>> like to see the standard support them.
>
> The standard /does/ support them - it simply does not mandate that an
> implementation supports them.  It's good to be accurate in your wording
> for a proposal like that.

In the proposal, I suggest:

    This adds unsigned long and unsigned long long to the +required+
    supported types for bit-fields.

> In my own code, I don't believe I have ever had need for types longer
> than "unsigned int" in bitfields - though I have certainly used the type
> "uint32_t" which happens to be "unsigned long" on several targets even
> though "unsigned int" is the same size.
>
> But I have a lot more use of smaller integer types.  And I use
> enumerated types in bitfields too, though these usually require a
> minimum size matching "int" (unless you use compiler-specific extensions
> to change that).
>
> I would suggest that it is pointless to add to the list of types
> mandated in the C standard here.  Rather, it should simply say that a
> bit-field shall have "an integer type".  That covers all sizes, shorter
> than int as well as longer, signed as well as unsigned.  After all,
> pretty much any serious modern C compiler will already support all
> integer types here.
>
> And I would also be even happier with "an integer type or enumerated type".

I agree.  If you're going to mandate support for additional types, why
not go all the way?

Currently, plain int bit fields have implementation-defined signedness.
I'm not a big fan of that rule, but logically it should be extended to
bit fields of other integer types specified without a "signed" or
"unsigned" keyword -- except that a plain char bit field should IMHO
have the same signedness as plain char.

Signed bit fields are questionably useful, but support for them is
already required, and I'm sure there's code that depends on them.

>> Here's  a draft of a proposal for that:
>> 
>> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html

"support" is misspelled in the Justification section.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#6226

Am 22.06.21 um 20:17 schrieb Keith Thompson:
>>
>> But I have a lot more use of smaller integer types.  And I use
>> enumerated types in bitfields too, though these usually require a
>> minimum size matching "int" (unless you use compiler-specific extensions
>> to change that).
>>
>> I would suggest that it is pointless to add to the list of types
>> mandated in the C standard here.  Rather, it should simply say that a
>> bit-field shall have "an integer type".  That covers all sizes, shorter
>> than int as well as longer, signed as well as unsigned.  After all,
>> pretty much any serious modern C compiler will already support all
>> integer types here.
>>
>> And I would also be even happier with "an integer type or enumerated type".
> 
> I agree.  If you're going to mandate support for additional types, why
> not go all the way?

I am worried that support for types smaller than int¹ and signed types²
could be controversial. So I'm trying to go for the two types that seem
most useful, most used, and, I hope, least controversial.

¹ People might disagree on questions of type and promotion.
² People might disagree on signed / unsigned for plain types and on
support for 1-bit bit-fields.

Philipp

P.S.: Even today, people disagree on some questions on the type of
bit-fields. Even implementations do (e.g. GCC vs. clang). And some say
that the standard is intentionally ambiguous to make the type
essentially implementation-defined.

P.P.S.: Thanks to everyone for the comments on wording.

[toc] | [prev] | [next] | [standalone]

#6227

On 23/06/2021 08:25, Philipp Klaus Krause wrote:
> Am 22.06.21 um 20:17 schrieb Keith Thompson:
>>>
>>> But I have a lot more use of smaller integer types.  And I use
>>> enumerated types in bitfields too, though these usually require a
>>> minimum size matching "int" (unless you use compiler-specific extensions
>>> to change that).
>>>
>>> I would suggest that it is pointless to add to the list of types
>>> mandated in the C standard here.  Rather, it should simply say that a
>>> bit-field shall have "an integer type".  That covers all sizes, shorter
>>> than int as well as longer, signed as well as unsigned.  After all,
>>> pretty much any serious modern C compiler will already support all
>>> integer types here.
>>>
>>> And I would also be even happier with "an integer type or enumerated type".
>>
>> I agree.  If you're going to mandate support for additional types, why
>> not go all the way?
> 
> I am worried that support for types smaller than int¹ and signed types²
> could be controversial. So I'm trying to go for the two types that seem
> most useful, most used, and, I hope, least controversial.
> 
> ¹ People might disagree on questions of type and promotion.
> ² People might disagree on signed / unsigned for plain types and on
> support for 1-bit bit-fields.
> 
> Philipp
> 
> P.S.: Even today, people disagree on some questions on the type of
> bit-fields. Even implementations do (e.g. GCC vs. clang). And some say
> that the standard is intentionally ambiguous to make the type
> essentially implementation-defined.
> 
> P.P.S.: Thanks to everyone for the comments on wording.
> 

I can appreciate your concerns about controversy.  However, I suspect (I
have no statistics, surveys, reports or evidence beyond a few samples)
there are two groups of people who use bitfields:

1. Those that stick to standards-mandated and guaranteed portable types
(bool, signed int, unsigned int).

2. Those that use types supported by the single compiler they use, or by
most real compilers (whatever integer type they want).

Who is your proposal for?  Who are you trying to help?

As it stands, it could help group 1 if they need longer unsigned types
in bitfields.  But it won't do anything much for group 2, who already
use many different sizes (including smaller sizes).  Group 2 programmers
outnumber group 1 programmers by orders of magnitude - relatively few C
programmers need to write fully portable C code restricted only to the
guarantees in the C standards, and those that do are unlikely to make
much use of bitfields because the specifications in the standards are so
weak.

If you follow my recommendation and mandate support for /all/ integer
types, then group 1 get significantly more flexibility and group 2 now
know that their code is more portable (though many details are still
implementation-dependent, at least they can expect the same results for
different compilers on the same target and ABI).  It's not going to make
a big difference to anyone, but it would be nice to have the standard
reflect common usage.

I agree that your more limited proposal is more likely to get accepted
than a wider one.  I simply don't think the limited version is worth the
effort - it needs to be wider to be of relevance in real code.  So,
IMVHO (and I'm not the one making or submitting the proposal) it makes
sense to gamble for the big prize, and risk rejection for the more
controversial proposal.

[toc] | [prev] | [next] | [standalone]

#6229

Am 23.06.21 um 08:59 schrieb David Brown:
> 
> Who is your proposal for?  Who are you trying to help?

Programmers that need bit-fields wider than 16 bits, and want them to be
(somewhat more) portable.

> If you follow my recommendation and mandate support for /all/ integer
> type

I think that goes too far. I don't want to mandate support for extended
integer types.

> 
> I agree that your more limited proposal is more likely to get accepted
> than a wider one.  I simply don't think the limited version is worth the
> effort - it needs to be wider to be of relevance in real code.  So,
> IMVHO (and I'm not the one making or submitting the proposal) it makes
> sense to gamble for the big prize, and risk rejection for the more
> controversial proposal.
> 

Some more far-reaching proposals on integers including bit-fields have
been rejected in the past.

I think I'll try to clean up my proposal for unsigned long and unsigned
long long, and add two questions at the end: "Does WG14 want to see a
proposal for further standard integer types along the lines of this
one?" and "Does WG14 want to see a proposal for bit-precise integer
types along the lines of this one?".

Philipp

[toc] | [prev] | [next] | [standalone]

#6231

On 23/06/2021 13:12, Philipp Klaus Krause wrote:
> Am 23.06.21 um 08:59 schrieb David Brown:
>>
>> Who is your proposal for?  Who are you trying to help?
> 
> Programmers that need bit-fields wider than 16 bits, and want them to be
> (somewhat more) portable.
> 
>> If you follow my recommendation and mandate support for /all/ integer
>> type
> 
> I think that goes too far. I don't want to mandate support for extended
> integer types.
> 

Given that no compiler (to my knowledge - and I'd be very interested in
counter-examples) actually has extended integer types, that is surely
not a problem.

>>
>> I agree that your more limited proposal is more likely to get accepted
>> than a wider one.  I simply don't think the limited version is worth the
>> effort - it needs to be wider to be of relevance in real code.  So,
>> IMVHO (and I'm not the one making or submitting the proposal) it makes
>> sense to gamble for the big prize, and risk rejection for the more
>> controversial proposal.
>>
> 
> Some more far-reaching proposals on integers including bit-fields have
> been rejected in the past.
> 
> I think I'll try to clean up my proposal for unsigned long and unsigned
> long long, and add two questions at the end: "Does WG14 want to see a
> proposal for further standard integer types along the lines of this
> one?" and "Does WG14 want to see a proposal for bit-precise integer
> types along the lines of this one?".
> 

The bit-precise (<stdint.h>) integer types are all defined in terms of
integer types.  (In theory, they could be extended integer types - in
practice, they are always standard integer types.)  So your second
question here is superfluous.

The first question would be a reasonable compromise between your
original more limited proposal, and the wider one.  I don't really know
how these proposals work, and how much they are all-or-nothing or for
questions and discussions, so you are in a better position to judge this
than I am.

[toc] | [prev] | [next] | [standalone]

#6232

> Given that no compiler (to my knowledge - and I'd be very interested in
> counter-examples) actually has extended integer types, that is surely
> not a problem.

I think they are mostly used in lesser-known compilers targeting
embedded systems; but AFAIK both GCC and clang have a 24-bit extended
integer type when targeting avr, also used as int24_t and uint24_t in
stdint.h.

> 
> The bit-precise (<stdint.h>) integer types are all defined in terms of
> integer types.  (In theory, they could be extended integer types - in
> practice, they are always standard integer types.)  So your second
> question here is superfluous.

I meant the C23 bit-precise integer types from stdbitint.h, as per N2709.

> 
> The first question would be a reasonable compromise between your
> original more limited proposal, and the wider one.  I don't really know
> how these proposals work, and how much they are all-or-nothing or for
> questions and discussions, so you are in a better position to judge this
> than I am.
> 

The proposal champion (usually an author, but can be someone else if no
author can attend the meeting) presents the proposal. Then there is a
discussion (with a time limit). Afterwards there usually are straw polls
on questions (usually suggested by the champion, but can be someone
else). Typical questions styles are "Does the comittee want <proposal>
for <next version of C standard>, as in Nxxxx?" (directly deciding) and
"Does the comittee want <proposal> along the lines of Nxxxx?" (to see
which direction to proceed, typically when the feeling from the
discussion is that the proposal needs further polishing, and the author
wants to know if it is worth doing so.

If you want to see some examples, have a look at the minutes fo a
meeting, e.g. N2691, though the words attributed to attendants there are
usually a summary of the stated position as perceived by the one writing
the minutes rather than the exact words (would be too long otherwise -
especially examples, references and arguments given to support the
position rarely appear in the minutes). Straw poll question wording and
results are AFAIK always exact though.

[toc] | [prev] | [next] | [standalone]

#6234

Philipp Klaus Krause <pkk@spth.de> writes:
>> Given that no compiler (to my knowledge - and I'd be very interested in
>> counter-examples) actually has extended integer types, that is surely
>> not a problem.
>
> I think they are mostly used in lesser-known compilers targeting
> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
> integer type when targeting avr, also used as int24_t and uint24_t in
> stdint.h.

gcc's documentation says "GCC does not support any extended integer types.".
I don't see anything about 24-bit integers.

[...]

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#6235

Am 23.06.21 um 19:22 schrieb Keith Thompson:
> Philipp Klaus Krause <pkk@spth.de> writes:
>>> Given that no compiler (to my knowledge - and I'd be very interested in
>>> counter-examples) actually has extended integer types, that is surely
>>> not a problem.
>>
>> I think they are mostly used in lesser-known compilers targeting
>> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
>> integer type when targeting avr, also used as int24_t and uint24_t in
>> stdint.h.
> 
> gcc's documentation says "GCC does not support any extended integer types.".
> I don't see anything about 24-bit integers.
> 
> [...]
> 

Hmm, https://gcc.gnu.org/wiki/avr-gcc mentions 24-bit integers. Maybe
they are 24-bit integers not considered extended integer types in the
sense of the standard? Though I don't know what they'd do that; AFAIK
that only makes sense if you want something that behaves like an integer
bigger than intmax_t.

[toc] | [prev] | [next] | [standalone]

#6238

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 23.06.21 um 19:22 schrieb Keith Thompson:
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>>> Given that no compiler (to my knowledge - and I'd be very interested in
>>>> counter-examples) actually has extended integer types, that is surely
>>>> not a problem.
>>>
>>> I think they are mostly used in lesser-known compilers targeting
>>> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
>>> integer type when targeting avr, also used as int24_t and uint24_t in
>>> stdint.h.
>> 
>> gcc's documentation says "GCC does not support any extended integer types.".
>> I don't see anything about 24-bit integers.
>> 
>> [...]
>
> Hmm, https://gcc.gnu.org/wiki/avr-gcc mentions 24-bit integers. Maybe
> they are 24-bit integers not considered extended integer types in the
> sense of the standard? Though I don't know what they'd do that; AFAIK
> that only makes sense if you want something that behaves like an integer
> bigger than intmax_t.

Interesting.  It does mention __int24 and __uint24 under "Extensions",
so apparently they're language extensions (allowed under 4p6) rather
than extended integer types.  Perhaps they don't meet all the
requirements of (extended) integer types.  Since the compiler appears
not to be fully conforming anyway, I'm not sure how much that matters
(except that it would have given us an example of extended integer types
in the wild).

Similarly, gcc supports __int128 and unsigned __int128 (note the
different syntax) as a language extension on some target systems.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#6240

On 24/06/2021 01:12, Keith Thompson wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 23.06.21 um 19:22 schrieb Keith Thompson:
>>> Philipp Klaus Krause <pkk@spth.de> writes:
>>>>> Given that no compiler (to my knowledge - and I'd be very interested in
>>>>> counter-examples) actually has extended integer types, that is surely
>>>>> not a problem.
>>>>
>>>> I think they are mostly used in lesser-known compilers targeting
>>>> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
>>>> integer type when targeting avr, also used as int24_t and uint24_t in
>>>> stdint.h.
>>>
>>> gcc's documentation says "GCC does not support any extended integer types.".
>>> I don't see anything about 24-bit integers.
>>>
>>> [...]
>>
>> Hmm, https://gcc.gnu.org/wiki/avr-gcc mentions 24-bit integers. Maybe
>> they are 24-bit integers not considered extended integer types in the
>> sense of the standard? Though I don't know what they'd do that; AFAIK
>> that only makes sense if you want something that behaves like an integer
>> bigger than intmax_t.
> 
> Interesting.  It does mention __int24 and __uint24 under "Extensions",
> so apparently they're language extensions (allowed under 4p6) rather
> than extended integer types.  Perhaps they don't meet all the
> requirements of (extended) integer types.  Since the compiler appears
> not to be fully conforming anyway, I'm not sure how much that matters
> (except that it would have given us an example of extended integer types
> in the wild).
> 

avr-gcc is very close to conforming (as freestanding rather than hosted)
these days, if you pick the right options (such as for 64-bit doubles).
 It is obviously limited by the size of the target devices (it's not
easy to have 1023 members in a struct on a device that might have 256
bytes of ram!).  And last I checked it was missing a few maths
functions, some wide character support, and a few other minor bits and
pieces.  Still, full conformance is not particularly important to users
of such embedded tools.

> Similarly, gcc supports __int128 and unsigned __int128 (note the
> different syntax) as a language extension on some target systems.
> 

[toc] | [prev] | [next] | [standalone]

#6239

On 23/06/2021 17:45, Philipp Klaus Krause wrote:
>> Given that no compiler (to my knowledge - and I'd be very interested in
>> counter-examples) actually has extended integer types, that is surely
>> not a problem.
> 
> I think they are mostly used in lesser-known compilers targeting
> embedded systems; but AFAIK both GCC and clang have a 24-bit extended
> integer type when targeting avr, also used as int24_t and uint24_t in
> stdint.h.
> 

I can't answer for clang.  But gcc explicitly says it does not support
any extended integer types:
<https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html>

For the AVR (an 8-bit device, in case anyone reading is unfamiliar) it
/does/ support certain 24-bit types.  In particular it supports 24-bit
pointers into a named address space "__memx", to handle generic pointers
as flash and ram are independent hardware address spaces on these
devices.  However, "void *" is still 16-bit, and uintptr_t is still
16-bit.  The 24-bit addresses are part of the named address extensions,
and not normal pointers.

And it supports a type "__int24" in the same manner as gcc on bigger
devices supports "__int128" - in most respects it works like an integer
type, but it specifically is /not/ an "extended integer type" (or an
"integer type") in C standards terms.  And that means that there is /no/
int24_t or uint24_t in a standards compliant C library for the AVR with
gcc.  You have to write "typedef __int24 int24_t;" yourself.

I would be surprised if clang is different from gcc here, but I have not
looked at it.

I don't know why gcc doesn't support 24-bit integers on the AVR as an
extended integer type - the prime reason it can't make __int128 into an
extended integer type on 64-bit systems is that it would need to change
the size of intmax_t, which would lead to all sorts of messes.

>>
>> The bit-precise (<stdint.h>) integer types are all defined in terms of
>> integer types.  (In theory, they could be extended integer types - in
>> practice, they are always standard integer types.)  So your second
>> question here is superfluous.
> 
> I meant the C23 bit-precise integer types from stdbitint.h, as per N2709.
> 

OK.  These are new to me, and I think it would be worth expanding on
that a little (giving the reference as you have here).  Now that I
understand it, I agree with that second question too.

>>
>> The first question would be a reasonable compromise between your
>> original more limited proposal, and the wider one.  I don't really know
>> how these proposals work, and how much they are all-or-nothing or for
>> questions and discussions, so you are in a better position to judge this
>> than I am.
>>
> 
> The proposal champion (usually an author, but can be someone else if no
> author can attend the meeting) presents the proposal. Then there is a
> discussion (with a time limit). Afterwards there usually are straw polls
> on questions (usually suggested by the champion, but can be someone
> else). Typical questions styles are "Does the comittee want <proposal>
> for <next version of C standard>, as in Nxxxx?" (directly deciding) and
> "Does the comittee want <proposal> along the lines of Nxxxx?" (to see
> which direction to proceed, typically when the feeling from the
> discussion is that the proposal needs further polishing, and the author
> wants to know if it is worth doing so.
> 
> If you want to see some examples, have a look at the minutes fo a
> meeting, e.g. N2691, though the words attributed to attendants there are
> usually a summary of the stated position as perceived by the one writing
> the minutes rather than the exact words (would be too long otherwise -
> especially examples, references and arguments given to support the
> position rarely appear in the minutes). Straw poll question wording and
> results are AFAIK always exact though.
> 

[toc] | [prev] | [next] | [standalone]

#6228

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 22.06.21 um 20:17 schrieb Keith Thompson:
>>>
>>> But I have a lot more use of smaller integer types.  And I use
>>> enumerated types in bitfields too, though these usually require a
>>> minimum size matching "int" (unless you use compiler-specific extensions
>>> to change that).
>>>
>>> I would suggest that it is pointless to add to the list of types
>>> mandated in the C standard here.  Rather, it should simply say that a
>>> bit-field shall have "an integer type".  That covers all sizes, shorter
>>> than int as well as longer, signed as well as unsigned.  After all,
>>> pretty much any serious modern C compiler will already support all
>>> integer types here.
>>>
>>> And I would also be even happier with "an integer type or enumerated type".
>> 
>> I agree.  If you're going to mandate support for additional types, why
>> not go all the way?
>
> I am worried that support for types smaller than int¹ and signed types²
> could be controversial. So I'm trying to go for the two types that seem
> most useful, most used, and, I hope, least controversial.
>
> ¹ People might disagree on questions of type and promotion.
> ² People might disagree on signed / unsigned for plain types and on
> support for 1-bit bit-fields.
>
> Philipp
>
> P.S.: Even today, people disagree on some questions on the type of
> bit-fields. Even implementations do (e.g. GCC vs. clang). And some say
> that the standard is intentionally ambiguous to make the type
> essentially implementation-defined.
>
> P.P.S.: Thanks to everyone for the comments on wording.

Are there any implementations that support bit fields of types other
than the required ones that *don't* support them for all integer types?
I dislike arbitrary restrictions, especially if most implementations
won't impose those restrictions anyway.  I wouldn't be surprised if all
implementations that support non-standard bit field types do so
consistently.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#6230

Am 22.06.21 um 16:49 schrieb Philipp Klaus Krause:
> Since bit-fields of type unsigned long and unsigned long long are
> useful, commonly suppoted by implementations, and commonly used, I'd
> like to see the standard support them.
> 
> Here's  a draft of a proposal for that:
> 
> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html
> 

I now realize that in some way, the type question is even harder for
types wider than int than for types narrower than it. We already have
divergence on the type between GCC and clang for unsigned int
bit-fields. But there it only matters when you use _Generic (i.e. for
clang _Generic on an unsigned int bit-field will match unsigned int, but
for clang it won't).
For other uses, we have the integer promotions that work on anything
smaller than int. So x.b << z behaves similar on GCC vs clang, since x.b
is promoted to int (there is still the difference of promoting to int
vs. promoting to unsigned int).
But for an unsigned long bit-field x.b << z will often give a different
result on GCC vs clang: The topmost bits of the result might be 1 for
clang where they are 0 for GCC (as clang does the shift on an unsigned
long, while GCC does it on a type just as wide as the bit-field).

[toc] | [prev] | [next] | [standalone]

#6233

Am 23.06.21 um 13:22 schrieb Philipp Klaus Krause:

> For other uses, we have the integer promotions that work on anything
> smaller than int. So x.b << z behaves similar on GCC vs clang, since x.b
> is promoted to int (there is still the difference of promoting to int
> vs. promoting to unsigned int).

My mistake here: they always promote to int, as per 6.3.1.1 of the
latest standard draft N2596.

[toc] | [prev] | [next] | [standalone]

#6236

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

> Since bit-fields of type unsigned long and unsigned long long are
> useful, commonly suppoted by implementations, and commonly used, I'd
> like to see the standard support them.
>
> Here's  a draft of a proposal for that:
>
> http://www.colecovision.eu/stuff/proposal-unsigned-long-bit-field.html

Here is a possible (and simpler) alternative.

Type specifier for bit-fields is _Bool, int, signed, or unsigned
(with signed int and unsigned int being synonymous with signed
and unsigned, respectively).

Bit-fields of type _Bool act just like they do now.

Bit-fields of type int are either the same as an unsigned
bit-field or the same as a signed bit-field, with the choice
being implementation-defined, just like they are now.

Bit-fields of types signed and unsigned may use widths up to the
widths of intmax_t and uintmax_t, respectively.

The type of a signed bit-field is the first of signed, long,
long long, and intmax_t, that is wide enough to hold all the
possible values of the bit-field.

The type of an unsigned bit-field is the first of unsigned,
unsigned long, unsigned long long, and uintmax_t, that is wide
enough to hold all the possible values of the bit-field.

For compatibility with current integer promotion rules, an access
for an unsigned bit-field whose range of possible values are all
representable within the range of signed int yields a value that
has been promoted to type signed int, just like such things are
done now.  In all other cases the type of a bit-field access
is the type of the bit-field, as stated above.

(Personally I like this approach better than allowing different
integer types as bit-field specifiers.)

[toc] | [prev] | [next] | [standalone]

#6237

Am 23.06.21 um 19:53 schrieb Tim Rentsch:
> Bit-fields of types signed and unsigned may use widths up to the
> widths of intmax_t and uintmax_t, respectively.
> 

WG14 usually doesn't like to use the same syntax as C++ but with a
different meaning.
AFAIK, in C++, you can have an int bit-field wider than int (or whatever
else the type is), but the upper bits then are padding bits.

[toc] | [prev] | [next] | [standalone]

#6243

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

> Am 23.06.21 um 19:53 schrieb Tim Rentsch:
>
>> Bit-fields of types signed and unsigned may use widths up to the
>> widths of intmax_t and uintmax_t, respectively.
>
> WG14 usually doesn't like to use the same syntax as C++ but with a
> different meaning.
> AFAIK, in C++, you can have an int bit-field wider than int (or whatever
> else the type is), but the upper bits then are padding bits.

The obvious answer is to ask the C++ committee to change their
silly rule.  And if they don't want to change it, just ignore it;
the C++ rule is already incompatible with C, now it will just be
incompatible in a different way.  The gap between C and C++ has
increased to the point where they should be treated as separate
and independent languages.

[toc] | [prev] | [next] | [standalone]

#6244

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 23.06.21 um 19:53 schrieb Tim Rentsch:
>>> Bit-fields of types signed and unsigned may use widths up to the
>>> widths of intmax_t and uintmax_t, respectively.
>>
>> WG14 usually doesn't like to use the same syntax as C++ but with a
>> different meaning.
>> AFAIK, in C++, you can have an int bit-field wider than int (or whatever
>> else the type is), but the upper bits then are padding bits.
>
> The obvious answer is to ask the C++ committee to change their
> silly rule.  And if they don't want to change it, just ignore it;
> the C++ rule is already incompatible with C, now it will just be
> incompatible in a different way.  The gap between C and C++ has
> increased to the point where they should be treated as separate
> and independent languages.

It's no more incompatible than any other C++ feature that doesn't exist
in C.  A program that defines a bit field with a length that exceeds the
width of the type is a constraint violation in C, and valid in C++.

On the other hand, I agree that the C++ rule *seems* silly.  I wonder
what the rationale is.  (The earliest reference to the rule that I found
is in the C++ 1998 standard.)

It would be nice to avoid *gratuitous* incompatibilities between C and
C++.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.std.c

csiph-web