James Kuyper <kuyper@wizard.net> writes:
>> I'm very annoyed by the fact that the simple notation provided by
>> bit-fields is unusable in portable code, simply because the standard
>> refused to be sufficiently specific.

Clive D.W. Feather wrote:
> It's perfectly usable in portable code. It just might not mean what
> you think it does.

James:
>> The more-portable (though still not
>> completely portable) equivalent operations using bitwise arithmetic
>> operators are far clumsier to use. I presume backward compatibility
>> with diverse implementations was the reason. A legitimate reason, but
>> still an annoying one.

Clive:
> The problem is that some people see most significant bits first as
> "intuitively obvious", and some don't.

I made a proposal some years ago (which was rejected) that a set
of macros be added to <limits.h> that described such implementation-
specific things like bitfield ordering, endianness, etc.  I intended
for them to be used to write very portable (or at least, more
portable) code that employed bitfields, et al.  For example:

    #include <limits.h>    /* With proposed additions */

    struct MyBits
    {
    #if _ORD_BITF_HL       /* Bitfields fill from high to low */
        unsigned    yr: 7;
        unsigned    mo: 4;
        unsigned    dy: 5;
    #else                  /* Bitfields fill from low to high */
        unsigned    dy: 5;
        unsigned    mo: 4;
        unsigned    yr: 7;
    #endif
    };

The resulting structure would have the same layout on any system
(assuming compatible word sizes), which might be important if
you're writing the struct data to files on one system that are
then transported to and read by a different system.

As it stands now, programmers who want to do just this sort of
thing must write their own porting header files, which I would
bet is a pretty widespread "existing practice".

(FWIW, I think my proposal was rejected because it was too
complicated, or because I didn't make it clear how useful the
macros could really be.  Pity.  For those who are curious, the
proposal is at <http://www.flash.net/~dtribble/text/c9xmach.txt>.)


-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 14 Jul 98 01:13:26 GMT, David R Tribble
<david.tribble@noSPAM.central.beasys.com> wrote:

snip

>I made a proposal some years ago (which was rejected) that a set
>of macros be added to <limits.h> that described such implementation-
>specific things like bitfield ordering, endianness, etc.  I intended
>for them to be used to write very portable (or at least, more
>portable) code that employed bitfields, et al.  For example:

snip

>As it stands now, programmers who want to do just this sort of
>thing must write their own porting header files, which I would
>bet is a pretty widespread "existing practice".
>
>(FWIW, I think my proposal was rejected because it was too
>complicated, or because I didn't make it clear how useful the
>macros could really be.  Pity.  For those who are curious, the
>proposal is at <http://www.flash.net/~dtribble/text/c9xmach.txt>.)

This sounds like it would have been useful. Is it likely something
like it will be discussed for the next version of the standard(s)? For
C++, you might want some templates in numeric_limits as well.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]