Announcing the birth of HAL 9000 (plus ObC) 
Author Message
 Announcing the birth of HAL 9000 (plus ObC)

I don't have a copy of the standard before me, but K&R 2 in page 150 says
that "Fields may be declared only as ints; for portability, specify signed
or unsigned explicitly."



[snippage about guesses relating to maximum bit field count]

Quote:
> Before my mind went down I concluded at first that the number could
> be 32767 * 8, which is the maximum portable size of an object multiplied
> with the minimum CHAR_BIT. This occured too big to me and before Dave
> removed another memory module I looked at the minimum maximum number
> of struct members, which The Standard says is 127. Have I overlooked
> something else which would change (probably reduce) this number further?



Fri, 02 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

Quote:

>I don't have a copy of the standard before me, but K&R 2 in page 150 says
>that "Fields may be declared only as ints; for portability, specify signed
>or unsigned explicitly."

But that's what I have done. All fields were unsigned. I know that
the maximum size of a *single* bitfield can't portably exceed 16,
the minimum number of bits in an unsigned int due to this reason.

But my understanding is that nothing can prevent me from putting
N bitfields of size 1 in a struct. To make it clear, I don't need
the bits laid out in a specific way in memory. All I want is
a container for a bunch of flags.

Again,

        struct {
                unsigned a : 1;     /* number 1 */
                unsigned b : 1;
                unsigned c : 1;
                /* ... */
                unsigned x : 1;     /* number N */
        } flags;

How big can N portably be?

Quote:


>[snippage about guesses relating to maximum bit field count]

>> Before my mind went down I concluded at first that the number could
>> be 32767 * 8, which is the maximum portable size of an object multiplied
>> with the minimum CHAR_BIT. This occured too big to me and before Dave
>> removed another memory module I looked at the minimum maximum number
>> of struct members, which The Standard says is 127. Have I overlooked
>> something else which would change (probably reduce) this number further?

        Jens
--

SIGSIG -- signature too long (core dumped)


Sun, 04 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)


Quote:

>But my understanding is that nothing can prevent me from putting
>N bitfields of size 1 in a struct. To make it clear, I don't need
>the bits laid out in a specific way in memory. All I want is
>a container for a bunch of flags.

using a char * and accessing the individual bits through logic
routines ( OR to set, AND to reset and XOR to toggle) should do the
trick.


Thu, 08 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

Quote:

>The standard says you can't put in more bits than fit in an int, no matter
>how they're organized.  You'll have to break them into sets.

Kevin, if I get you right the Standard says

        struct {
                unsigned b1 : 1;
                unsigned b2 : 1;
                unsigned b3 : 1;
                unsigned b4 : 1;
                /* ... */
                unsigned b17 : 1;
        } an_enjoyable_game;

is nonportable? Somewhere deep in my subconscious there is a voice that
whispers "this is perfectly portable because the compiler is allowed to
put b17 in a new machine word." So the portability restriction on 16 bits
per int is not applicable here. The next limit AFAICT is 127, the
maximum portable struct members.

If you can cite chapter and verse that this is wrong I'll promise
to shut up. My original posting also went to comp.std.c but the
regulars there apparently don't find this question too interesting
and I still do not have an authoritative answer on this.

[It may not have actually gone there, my software automatically eats
 crossposts unless I put in magic to okay them, which I don't unless I
 notice them and approve of them. -mod]

(I got some replies from helpful souls with advice on handling
large "arrays of bits" using macros -- thanks. My interest in
this question is rather a standards technical one, however.)

Quote:
>--
>#include <standard.disclaimer>
> _
>Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
>Per the FCA, this email address may not be added to any commercial mail list

        Jens
--

SIGSIG -- signature too long (core dumped)


Fri, 09 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

Quote:

> >But my understanding is that nothing can prevent me from putting
> >N bitfields of size 1 in a struct. To make it clear, I don't need
> >the bits laid out in a specific way in memory. All I want is
> >a container for a bunch of flags.

Right.

Quote:
> using a char * and accessing the individual bits through logic
> routines ( OR to set, AND to reset and XOR to toggle) should do the
> trick.

Use unsigned char, if you want to use this trick. Note that (as
explained in an article of mine posted to c.l.c I think), bit
opeartions act on the value of an expression, not on the stored bits
in an object. Only for unsigned or positive quantities is the relation
between bits and value completely transparent.

If you are doing some shifts etc., an unsigned char cast to unsigned
int might be better to avoid the unsigned char getting promoted to the
signed type int.

Cheers
Tanmoy
--

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 ]



Fri, 09 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

[snip]

Quote:
> If you can cite chapter and verse that this is wrong I'll promise
> to shut up.

[snip]

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

This supports your argument.  I don't see any other constraints on the
size of a bit-field.
--

PGP public key and home page at http://www.msu.edu/user/pfaffben



Fri, 09 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

[snip]

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

     What is "an ordinary object"?  short, int, long, the longest of
these, implementation defined, something else?

[snip]

Sincerely,

Gene Wirchenko

C Pronunciation Guide:
     y=x++;     "wye equals ex plus plus semicolon"
     x=x++;     "ex equals ex doublecross semicolon"



Mon, 12 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

Quote:


>[snip]
>> If you can cite chapter and verse that this is wrong I'll promise
>> to shut up.
>[snip]

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

>This supports your argument.  I don't see any other constraints on the
>size of a bit-field.

Right. This is what the Standard says about the size of a *single*
bitfield. No doubt about it -- 16 is the maximum portable number.
But if I have *more* than one bitfield, then I can put 127 of them
in a struct and remain portable, can't I?

Apoplogies to everyone if I was unclear in my original question. Some
confusion may have arisen because the term "bitfield" is understood by
some as "the *collection* of members declared in bitfield style",
whereas I read the Standard as making this structure

        struct {
                unsigned b1 : 1;
                unsigned b2 : 1;
                /* ... */
                unsigned b17 : 1;
        } I_could_read_your_lips_Dave;

contain seven{*filter*} different bitfields (of one bit each).

        Jens
--

SIGSIG -- signature too long (core dumped)



Mon, 12 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)


: >The standard says you can't put in more bits than fit in an int, no matter
: >how they're organized.  You'll have to break them into sets.

: Kevin, if I get you right the Standard says

:       struct {
:               unsigned b1 : 1;
:               unsigned b2 : 1;
:               unsigned b3 : 1;
:               unsigned b4 : 1;
:               /* ... */
:               unsigned b17 : 1;
:       } an_enjoyable_game;

: is nonportable? Somewhere deep in my subconscious there is a voice that
: whispers "this is perfectly portable because the compiler is allowed to
: put b17 in a new machine word." So the portability restriction on 16 bits
: per int is not applicable here.
[...]

My reading of the standard says that the above is perfectly legal.  
What is *not* legal/portable is:

        struct {
                unsigned b17:17;
                /* ... */
        } bad_bad_bad;

--
*******************************************************************

Novell IS & T, Bracknell, England             +44-1344-724031
*******************************************************************
*        if (status = UNDER_NUCLEAR_ATTACK)                       *
*               launch_full_counterstrike();                      *
*******************************************************************
(C) 1997 M.F.Sohnius -- free distribution on USENET
       (Not a spokesperson  -- just a cyclist!)



Tue, 13 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

Jens Schweikhardt:

Quote:
> Apoplogies to everyone if I was unclear in my original question. Some
> confusion may have arisen because the term "bitfield" is understood by
> some as "the *collection* of members declared in bitfield style",
> whereas I read the Standard as making this structure

>    struct {
>            unsigned b1 : 1;
>            unsigned b2 : 1;
>            /* ... */
>            unsigned b17 : 1;
>    } I_could_read_your_lips_Dave;

> contain seven{*filter*} different bitfields (of one bit each).

So that's it!  I wondered why so many people were getting this wrong.
Jens is quite right -- in the language of the standard, that struct
contains 17 bit-fields (the standard hyphenates the word).  It also
requires them to be packed into "addressable storage units"; with today's
typical machines there will either be one, two, or three of these.
(They could be single 8-bit bytes since the bit-fields in this example
are smaller than that.)  But the number of bit-fields is 17.  17 is the
number thou shalt count, not 18, and 19 is right out.... [Sorry :-)]

Quote:
> ... then I can put 127 of them in a struct and remain portable, can't I?

Not really.  Section 5.2.4.1/2.2.4.1 of the standard says:

# The implementation shall be able to translate and execute at least one
# program that contains at least one instance of every one of the following
# limits:

And there is a footnote to this:

* Implementations should avoid imposing fixed translation limits whenever
  possible.

Remember that footnotes may convey clarification or suggestions but are not
officially part of the standard.

The applicable one of the limits listed is:

# 127 members in a single structure or union.

But look again at the first part.  What the standard is really saying is
that *if*, contrary to recommendation, an implementation imposes a fixed
limit on the number of members in a struct, that limit must be at least
127 members.  On the other hand, an implementation that allows 1000-member
structs sometimes but in other situations, when resources are tighter,
limits structs to 20 members *could be conforming*, so long as one program
exists that exercises all the limits mentioned in the standard and that
the implementation can translate and execute.

So for this reason, the description of 127 members as the "portable limit"
is wrong.  And this clarification applies generally to this sort of limit
in ANSI C.
--

SoftQuad Inc., Toronto       then use lint (or Chris Torek...)" -- Joe English

My text in this article is in the public domain.



Tue, 13 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)

<snip>

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

>      What is "an ordinary object"?  short, int, long, the longest of
> these, implementation defined, something else?

Whatever is the type of the bitfield :-)

Cheers
Tanmoy
--

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 ]



Tue, 13 Jul 1999 03:00:00 GMT  
 Announcing the birth of HAL 9000 (plus ObC)



 > >> If you can cite chapter and verse that this is wrong I'll promise
 > >> to shut up.
 > >6.5.2.1:
 > >      "The expression that specifies the width of a bit-field shall
 > >be an integral constant expression that has nonnegative value that
 > >shall not exceed the number of bits in an ordinary object of
 > >compatible type."
 > >This supports your argument.  I don't see any other constraints on the
 > >size of a bit-field.
 > Right. This is what the Standard says about the size of a *single*
 > bitfield. No doubt about it -- 16 is the maximum portable number.
 > But if I have *more* than one bitfield, then I can put 127 of them
 > in a struct and remain portable, can't I?

Yes.  That's what I meant.  Since the Standard doesn't put any special
limit on the number of bitfields in a struct, therefore you can have
at least 127.
--

PGP public key and home page at http://www.msu.edu/user/pfaffben



Wed, 14 Jul 1999 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Value of a real Deathstation 9000?

2. HP Workstation 9000

3. help: main fortran calling C++ module on HP 9000 platform

4. ISO 9000 certified compilers

5. Ansi C compilers/debuggers for HP 9000/800?

6. BYTE ALIGNMENT FOR HP-9000

7. Diabolical plus plus

8. Happy birthday, HAL

9. paths.h on HP-9000/715 ??? Where is it ?

10. ** Is it a BUG in GDI plus? **

11. S-Plus

12. Show Plus/Minus in TreeView...

 

 
Powered by phpBB® Forum Software