🚀 go-pugleaf

In article <nzRPxQ9ytZZA084yn@csn.net>
thads@csn.net (Thad Smith) writes:

TS: Can the size of a bit-field, measured in bits, exceed the size of an
TS: int?  The description of bit-fields describes it as an integral
TS: type with a (programmer-)specified number of bits, not specifically
TS: constrained in size.  ANSI Classic section 3.2.1.1 says, however, that
TS: bit-fields are promoted to either int or unsigned int.  This would
TS: seem to prohibit promoting a large bit-field to a long.  If so, why
TS: was this constraint imposed?

6.5.2.1 constraints: The expression that specifies the width of a
bit-field ... shall not exceed the number of bits in an ordinary
object of compatible type.

So, the number of bits cannot exceed the number of bits in an int or
unsigned int.

TS: 
TS: Secondly, is the storage unit within which bit-fields are allocated
TS: constrained to be a single size or can it vary, depending on the size
TS: of the bit fields?  I see nothing in the standard prohibiting
TS: different size storage units for bit-fields.  Also bit-fields are

Neither do I.

TS: explicitly allowed to span multiple storage units, at least if the
TS: bit-field is not the first in a structure (the use of the word "may"
TS: makes the requirement for the first bit-field ambiguous with regard to
TS: storage in a single unit).

Depends on whether an addressable storage unit has to occur in
multiples of bytes. (The standard says that bytes are addressable
storage units, but not the converse. If addressable means that & can
be applied to it, again, the smallest addressable unit is a byte). If
it has to, then a width 4 bit field followed by width 2 bit field must
both belong to the same addressable storage unit, and neither can span
storage units.

TS: 
TS: If different size storage units are allowed or any bit-field is
TS: allowed to span multiple units, the size of a struct containing
TS: bit-fields might be 1 byte, while bit-fields could be allocated up to
TS: the size (in bits) of ints, possibly four bytes in a particular
TS: implementation, by choosing larger storage units for larger
TS: bit-fields.

I guess so.

TS: 
TS: Is anyone aware of an implementation using bit-field storage units
TS: smaller than int?

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

In article <nzRPxQ9ytZZA084yn@csn.net>, thads@csn.net (Thad Smith) writes:
> Can the size of a bit-field, measured in bits, exceed the size of an
> int?  The description of bit-fields describes it as an integral
> type with a (programmer-)specified number of bits, not specifically
> constrained in size.  ANSI Classic section 3.2.1.1 says, however, that
> bit-fields are promoted to either int or unsigned int.  This would
> seem to prohibit promoting a large bit-field to a long.  If so, why
> was this constraint imposed?

No.  ANSI Classic 3.5.2.1:

	The expression that specifies the width of a bit-field shall be
	an integral constant expression that nas nonnegative value that
	shall not exceed the number of bits in an ordinary object of
	compatible type.

The constraint is historical, probably because extracting a bit-field
that is longer than a word is sufficiently complicated as to be contrary
to the ``spirit of C''.

> Secondly, is the storage unit within which bit-fields are allocated
> constrained to be a single size or can it vary, depending on the size
> of the bit fields?  I see nothing in the standard prohibiting
> different size storage units for bit-fields.  Also bit-fields are
> explicitly allowed to span multiple storage units, at least if the
> bit-field is not the first in a structure (the use of the word "may"
> makes the requirement for the first bit-field ambiguous with regard to
> storage in a single unit).

It can vary (my emphasis):

	An implementation may allocate *any* addressable storage unit
	large enough to hold a bit-field.

Thus, an implementation is free to allocate a char for a 1 bit field and
an int for a 14 bit field.

> If different size storage units are allowed or any bit-field is
> allowed to span multiple units, the size of a struct containing
> bit-fields might be 1 byte, while bit-fields could be allocated up to
> the size (in bits) of ints, possibly four bytes in a particular
> implementation, by choosing larger storage units for larger
> bit-fields.

Correct.

> Is anyone aware of an implementation using bit-field storage units
> smaller than int?

Lots of them.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
In my opinion, we don't devote nearly enough scientific research
to finding a cure for jerks. -- Calvin

In article <uYgPxQ9ytt9W084yn@csn.net>
thads@csn.net (Thad Smith) writes:

TS: In article <4hkgds$bbh@info1.sdrc.com>,
TS: larry.jones@sdrc.com (Larry Jones) wrote:
TS: >In article <nzRPxQ9ytZZA084yn@csn.net>, thads@csn.net (Thad Smith) writes:
TS: >> Can the size of a bit-field, measured in bits, exceed the size of an
TS: >> int?  The description of bit-fields describes it as an integral
TS: >> type with a (programmer-)specified number of bits, not specifically
TS: >> constrained in size.  ANSI Classic section 3.2.1.1 says, however, that
TS: >> bit-fields are promoted to either int or unsigned int.  
TS: >
TS: >No.  ANSI Classic 3.5.2.1:
TS: >
TS: >	The expression that specifies the width of a bit-field shall be
TS: >	an integral constant expression that nas nonnegative value that
TS: >	shall not exceed the number of bits in an ordinary object of
TS: >	compatible type.
TS: >
TS: >The constraint is historical, probably because extracting a bit-field
TS: >that is longer than a word is sufficiently complicated as to be contrary
TS: >to the ``spirit of C''.
TS: 
TS: What does "ordinary object of compatible type" mean?  Could that mean
TS: long?  I now think that an implementation could allow specification of

I don't think so. The bit fields are either int or unsigned, an
ordinary object of compatible type is therefore an int or an
unsigned. If bitfields could be `long', it would have allowed long.

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

In article <nzRPxQ9ytZZA084yn@csn.net>, thads@csn.net (Thad Smith) writes:
>Can the size of a bit-field, measured in bits, exceed the size of an int?

A program that attempts to do it would have undefined behavior, but a kind
implementation would define it by extension.  On the other hand, an unkind
implementation could make all bit-fields exceed the size of an int.

>The description of bit-fields describes it as an integral type with a
>(programmer-)specified number of bits, not specifically constrained in size.

Not quite.  ANSI Classic section 3.5.2.1, page 61 lines 15 to 17, has a
Constraint requiring the specified width to fit in the number of bits in
an ordinary object of compatible type.  So if the type is int then this
constraint has the effect you say.  However, line 30 is a Semantic (not
Constraint) restricting the size.  So, a non-strictly-conforming program
can take advantage of an implementation extension without even getting a
diagnostic.

>ANSI Classic section 3.2.1.1 says, however, that bit-fields are promoted
>to either int or unsigned int.  This would seem to prohibit promoting a
>large bit-field to a long.  If so, why was this constraint imposed?

Probably the same reason as most other defects in the standard :-)

>Secondly, is the storage unit within which bit-fields are allocated
>constrained to be a single size or can it vary, depending on the size
>of the bit fields?  I see nothing in the standard prohibiting
>different size storage units for bit-fields.

Neither do I.  On the other hand, alignment is stated to be unspecified.
Therefore the silence on variable sizing is ambiguous.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer

In article <4hkgds$bbh@info1.sdrc.com>, I wrote (quoting the standard):
>
>	The expression that specifies the width of a bit-field shall be
>	an integral constant expression that nas nonnegative value that
>	shall not exceed the number of bits in an ordinary object of
>	compatible type.

In article <uYgPxQ9ytt9W084yn@csn.net>, thads@csn.net (Thad Smith) writes:
> What does "ordinary object of compatible type" mean?  Could that mean
> long?  I now think that an implementation could allow specification of
> a number of bits greater than int, but less than or equal to bits in
> long.  To access the value, the programmer casts the bit-field to long
> or unsigned long.  The cast would preceed the integral promotion, I
> think, and allow access to the longer value.

An ordinary object (i.e., not a bit-field) with the same type as the
declared type of the bit-field which is required to be int, signed int,
or unsigned int.  As Norm Diamond pointed out, that requirement is in
semantics, not constraints, so an implementation is free to add an
extension allowing other types (like long), and some do.  Such
implementations presumably extend the integral promotion rules in the
obvious fashion as well in order to eliminate the need for casts.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
Santa's gonna skip this block for years. -- Calvin

In article <4hn3mg$c9v@info1.sdrc.com>, larry.jones@sdrc.com (Larry Jones) writes:
# (quoting the standard):
# The expression that specifies the width of a bit-field shall be
# an integral constant expression that nas nonnegative value that
# shall not exceed the number of bits in an ordinary object of
# compatible type.
#
>In article <uYgPxQ9ytt9W084yn@csn.net>, thads@csn.net (Thad Smith) writes:
>> What does "ordinary object of compatible type" mean?  Could that mean
>> long?  I now think that an implementation could allow specification of
>> a number of bits greater than int, but less than or equal to bits in
>> long.  To access the value, the programmer casts the bit-field to long
>> or unsigned long.  The cast would preceed the integral promotion, I
>> think, and allow access to the longer value.

>An ordinary object (i.e., not a bit-field) with the same type as the
>declared type of the bit-field which is required to be int, signed int,
>or unsigned int.  As Norm Diamond pointed out, that requirement is in
>semantics, not constraints, so an implementation is free to add an
>extension allowing other types (like long), and some do.

Although I'm missing half the postings in this thread, everything sounds
right so far.

>Such implementations presumably extend the integral promotion rules in
>the obvious fashion as well in order to eliminate the need for casts.

They cannot.  As Thad Smith's original posting pointed out, the standard
prohibits this extension.  And as Mr. Smith's later posting points out,
as quoted above, a cast could do it.  In order to permit implementations
to provide this further extension without requiring casts, it would be
necessary to revise the wording in ANSI Classic section 3.2.1.1, page 35
lines 12 to 15.  These lines (originally quoted my Mr. Smith) currently
force the bit-field value into an int or unsigned int regardless.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer

In article <4ho846$g2d@usenet.pa.dec.com>, diamond@tbj.dec.com (Norman Diamond) writes:
> In article <4hn3mg$c9v@info1.sdrc.com>, larry.jones@sdrc.com (Larry Jones) writes:
> >Such implementations presumably extend the integral promotion rules in
> >the obvious fashion as well in order to eliminate the need for casts.
> 
> They cannot.  As Thad Smith's original posting pointed out, the standard
> prohibits this extension.

Sure they can -- once you've declared a bit-field with a non-conforming
type you've invoked undefined behavior and the compiler is at liberty to
do anything it likes from then on.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
I wonder what's on TV now. -- Calvin

tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya) wrote:


>TS: 
>TS: Is anyone aware of an implementation using bit-field storage units
>TS: smaller than int?

I am involved with embeded system development tools and there are
several compilers for the 8-bit end of the market that offer char
sized bitfields.

HiTech Software and IAR Systems to mention just two.

Both of these vendors have 16 and 32 bit compilers and I guess they
probably offer them there too.

The main usage is to beable to declare structrues which represent
hardware registers and I/O devices.

Regards
Sid

--
Sid Price - sidprice@softtools.com
Software Tools for Embedded System Development

In article <4hpkcv$gjc@info1.sdrc.com> larry.jones@sdrc.com "Larry Jones" writes:

>Sure they can -- once you've declared a bit-field with a non-conforming
>type you've invoked undefined behavior and the compiler is at liberty to
>do anything it likes from then on.

There is a curious case here however. Lets say (with reference to 6.5.2.1)
I declare:

struct bit {
    long field : CHAR_BIT*sizeof(long) + 1;
};

This results in undefined behaviour due to the long type of the declarator.
However a constraint is also violated due to the field width. Is a diagnostic
still required in this case or can the compiler omit it as a form of undefined
behaviour?

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

In article <827022001snz@genesis.demon.co.uk>, Lawrence Kirby <fred@genesis.demon.co.uk> writes:
> This results in undefined behaviour due to the long type of the declarator.
> However a constraint is also violated due to the field width. Is a diagnostic
> still required in this case or can the compiler omit it as a form of undefined
> behaviour?

That question was asked in an early Defect Report; the diagnostic is
still required.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
Oh yeah?  You just wait! -- Calvin

Lawrence Kirby (fred@genesis.demon.co.uk) wrote:
>There is a curious case here however. Lets say (with reference to 6.5.2.1)
>I declare:
>
>struct bit {
>    long field : CHAR_BIT*sizeof(long) + 1;
>};
>
>This results in undefined behaviour due to the long type of the declarator.
>However a constraint is also violated due to the field width. Is a diagnostic
>still required in this case or can the compiler omit it as a form of undefined
>behaviour?

TC1 requires all constraint violations to be diagnosed, even if undefined
behavior is involved. 

-- 
Eric Amick			eamick@clark.net
Columbia, MD			Public key available via finger

In article <827022001snz@genesis.demon.co.uk>, Lawrence Kirby <fred@genesis.demon.co.uk> writes:
>In article <4hpkcv$gjc@info1.sdrc.com> larry.jones@sdrc.com "Larry Jones" writes:
>>Sure they can -- once you've declared a bit-field with a non-conforming
>>type you've invoked undefined behavior and the compiler is at liberty to
>>do anything it likes from then on.

>Lets say (with reference to 6.5.2.1) I declare:
>  struct bit { long field : CHAR_BIT*sizeof(long) + 1; };
>This results in undefined behaviour due to the long type of the declarator.
>However a constraint is also violated due to the field width. Is a diagnostic
>still required in this case or can the compiler omit it as a form of undefined
>behaviour?

If I understand correctly, a technical corrigendum requires that a
diagnostic be issued for a translation unit which violates any syntax
rule or constraint, even if violations of other clauses occur "earlier"
in the translation unit.

From one point of view, I am glad to see that requirement.  From a
different point of view, I fear that even highest quality implementations
are now forced to issue a blanket warning at the beginning of translation.
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer