What does this represent?

unsigned int n : 6;

???

Saverio

saverio.post@gmail.com said:

> What does this represent?
>
> unsigned int n : 6;

See "The C Programming Language", 2nd edition, by Kernighan and Ritchie,
pages 149-150.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

> > What does this represent?
> > unsigned int n : 6;

Inside a structure or union, it represents an unsigned integral
bitfield that occupies 6 bits;
Outside a structure or union, it represents a syntax error.
Have fun.

On 12 Apr 2008 at 15:17, Yunzhong wrote:
>> > What does this represent?
>> > unsigned int n : 6;
>
> Inside a structure or union, it represents an unsigned integral
> bitfield that occupies 6 bits;

Perhaps the OP will wonder why such a thing could be useful.

A couple of common examples where bitfields are used are device drivers,
because combinations of flags (i.e. bits) are often stored in a single
byte in hardware; and binary data formats, which frequently contain
fields that aren't aligned at byte boundaries. Whether you realize it or
not, you're relying on bitfields every time you send an IP packet!
Here's the IP header struct that's used in every packet:

struct iphdr {
unsigned int version:4;
unsigned int ihl:4;
u_int8_t tos;
u_int16_t tot_len;
u_int16_t id;
u_int16_t frag_off;
u_int8_t ttl;
u_int8_t protocol;
u_int16_t check;
u_int32_t saddr;
u_int32_t daddr;
};

On Apr 12, 12:11pm, Antoninus Twink <nos...@nospam.invalid> wrote:
> On 12 Apr 2008 at 15:17, Yunzhong wrote:
>
> >> > What does this represent?
> >> > unsigned int n : 6;
>
> > Inside a structure or union, it represents an unsigned integral
> > bitfield that occupies 6 bits;
>
> Perhaps the OP will wonder why such a thing could be useful.
>
> A couple of common examples where bitfields are used are device drivers,
> because combinations of flags (i.e. bits) are often stored in a single
> byte in hardware; and binary data formats, which frequently contain
> fields that aren't aligned at byte boundaries. Whether you realize it or
> not, you're relying on bitfields every time you send an IP packet!
> Here's the IP header struct that's used in every packet:
>
> struct iphdr {
> unsigned int version:4;
> unsigned int ihl:4;
> u_int8_t tos;
> u_int16_t tot_len;
> u_int16_t id;
> u_int16_t frag_off;
> u_int8_t ttl;
> u_int8_t protocol;
> u_int16_t check;
> u_int32_t saddr;
> u_int32_t daddr;
>
>
>
> };


Even assuming reasonable definitions for those types...

You realize, of course, that the structure you've described will not
work on any x86 machine (nor any other little endian machine), and is
dependant on the order in which bit fields are stored (again wrong for
most x86 implementations), and assumes you can actually used bit
fields on an unsigned char (assuming one makes the obvious correction
to your code) on the implementation in question.

So almost assuredly, the OP is *not* sending IP packets via such a
structure.

On 14 Apr 2008 at 21:50, robertwessel2@yahoo.com wrote:
> On Apr 12, 12:11Âpm, Antoninus Twink <nos...@nospam.invalid> wrote:
>> Here's the IP header struct that's used in every packet:
>>
>> struct iphdr {
>> Â unsigned int version:4;
>> Â unsigned int ihl:4;
>> Â u_int8_t tos;
>> Â u_int16_t tot_len;
>> Â u_int16_t id;
>> Â u_int16_t frag_off;
>> Â u_int8_t ttl;
>> Â u_int8_t protocol;
>> Â u_int16_t check;
>> Â u_int32_t saddr;
>> Â u_int32_t daddr;
>>
>>
>>
>> };
>
>
> Even assuming reasonable definitions for those types...
>
> You realize, of course, that the structure you've described will not
> work on any x86 machine (nor any other little endian machine), and is
> dependant on the order in which bit fields are stored (again wrong for
> most x86 implementations), and assumes you can actually used bit
> fields on an unsigned char (assuming one makes the obvious correction
> to your code) on the implementation in question.
>
> So almost assuredly, the OP is *not* sending IP packets via such a
> structure.

Thanks for the clarification. You're right that the first two
(bit)fields may need to be swapped depending on endianness, but really
the main point was just that bitfields show up in very common protocols.

On Apr 14, 4:50 pm, "robertwess...@yahoo.com"
<robertwess...@yahoo.com> wrote:
> On Apr 12, 12:11 pm, Antoninus Twink <nos...@nospam.invalid> wrote:
>
>
>
> > On 12 Apr 2008 at 15:17, Yunzhong wrote:
>
> > >> > What does this represent?
> > >> > unsigned int n : 6;
>
> > > Inside a structure or union, it represents an unsigned integral
> > > bitfield that occupies 6 bits;
>
> > Perhaps the OP will wonder why such a thing could be useful.
>
> > A couple of common examples where bitfields are used are device drivers,
> > because combinations of flags (i.e. bits) are often stored in a single
> > byte in hardware; and binary data formats, which frequently contain
> > fields that aren't aligned at byte boundaries. Whether you realize it or
> > not, you're relying on bitfields every time you send an IP packet!
> > Here's the IP header struct that's used in every packet:
>
> > struct iphdr {
> > unsigned int version:4;
> > unsigned int ihl:4;
> > u_int8_t tos;
> > u_int16_t tot_len;
> > u_int16_t id;
> > u_int16_t frag_off;
> > u_int8_t ttl;
> > u_int8_t protocol;
> > u_int16_t check;
> > u_int32_t saddr;
> > u_int32_t daddr;
>
> > };
>
> Even assuming reasonable definitions for those types...
>
> You realize, of course, that the structure you've described will not
> work on any x86 machine (nor any other little endian machine), and is
> dependant on the order in which bit fields are stored (again wrong for
> most x86 implementations),

Yes.

> and assumes you can actually used bit
> fields on an unsigned char (assuming one makes the obvious correction
> to your code) on the implementation in question.

What correction and what about unsigned char? Here's the piece
of glibc header:

struct iphdr
{
#if __BYTE_ORDER == __LITTLE_ENDIAN
unsigned int ihl:4;
unsigned int version:4;
#elif __BYTE_ORDER == __BIG_ENDIAN
unsigned int version:4;
unsigned int ihl:4;
#else
# error "Please fix <bits/endian.h>"
#endif
u_int8_t tos;
u_int16_t tot_len;
u_int16_t id;
u_int16_t frag_off;
u_int8_t ttl;
u_int8_t protocol;
u_int16_t check;
u_int32_t saddr;
u_int32_t daddr;
/*The options start here. */
};

> So almost assuredly, the OP is *not* sending IP packets via such a
> structure.

Almost assuredly, OP is not using a fancy apple or sun machine, true.
(That code most certainly needs gcc or gcc-compatible compiler,
but that's something almost assuredly used by OP, indirectly)

Yevgen

On Apr 14, 5:20pm, ymunt...@gmail.com wrote:
> On Apr 14, 4:50 pm, "robertwess...@yahoo.com"
>
>
>
>
>
> <robertwess...@yahoo.com> wrote:
> > On Apr 12, 12:11 pm, Antoninus Twink <nos...@nospam.invalid> wrote:
>
> > > On 12 Apr 2008 at 15:17, Yunzhong wrote:
>
> > > >> > What does this represent?
> > > >> > unsigned int n : 6;
>
> > > > Inside a structure or union, it represents an unsigned integral
> > > > bitfield that occupies 6 bits;
>
> > > Perhaps the OP will wonder why such a thing could be useful.
>
> > > A couple of common examples where bitfields are used are device drivers,
> > > because combinations of flags (i.e. bits) are often stored in a single
> > > byte in hardware; and binary data formats, which frequently contain
> > > fields that aren't aligned at byte boundaries. Whether you realize it or
> > > not, you're relying on bitfields every time you send an IP packet!
> > > Here's the IP header struct that's used in every packet:
>
> > > struct iphdr {
> > > unsigned int version:4;
> > > unsigned int ihl:4;
> > > u_int8_t tos;
> > > u_int16_t tot_len;
> > > u_int16_t id;
> > > u_int16_t frag_off;
> > > u_int8_t ttl;
> > > u_int8_t protocol;
> > > u_int16_t check;
> > > u_int32_t saddr;
> > > u_int32_t daddr;
>
> > > };
>
> > Even assuming reasonable definitions for those types...
>
> > You realize, of course, that the structure you've described will not
> > work on any x86 machine (nor any other little endian machine), and is
> > dependant on the order in which bit fields are stored (again wrong for
> > most x86 implementations),
>
> Yes.
>
> > and assumes you can actually used bit
> > fields on an unsigned char (assuming one makes the obvious correction
> > to your code) on the implementation in question.
>
> What correction and what about unsigned char? Here's the piece
> of glibc header:
>
> struct iphdr
> {
> #if __BYTE_ORDER == __LITTLE_ENDIAN
> unsigned int ihl:4;
> unsigned int version:4;
> #elif __BYTE_ORDER == __BIG_ENDIAN
> unsigned int version:4;
> unsigned int ihl:4;
> #else
> # error "Please fix <bits/endian.h>"
> #endif
> u_int8_t tos;
> u_int16_t tot_len;
> u_int16_t id;
> u_int16_t frag_off;
> u_int8_t ttl;
> u_int8_t protocol;
> u_int16_t check;
> u_int32_t saddr;
> u_int32_t daddr;
> /*The options start here. */
> };
>
> > So almost assuredly, the OP is *not* sending IP packets via such a
> > structure.
>
> Almost assuredly, OP is not using a fancy apple or sun machine, true.
> (That code most certainly needs gcc or gcc-compatible compiler,
> but that's something almost assuredly used by OP, indirectly)


Well, the #ifdefs pretty solidly prove my point about bit field
order. And of course the byte order on the other stuff still needs to
be patched up with htons() and friends. OTOH, the beginning of the
structure are incorrect in most cases - the first eight bits are the
protocol version and header length - on many implementations bit
fields will always be stored in ints.

The structure as presented would have *not* been correct on almost any
x86 implementation (actually on none that I know of, and I frankly
doubt there are any where it would have been). And the modified one
you presented (or perhaps we should call that the unmodified one?),
using GCC extensions, would not, for example, be correct on any
Windows machine (where a bit field based on "int" would get a 32 bit
base type).

On Apr 12, 7:36am, saverio.p...@gmail.com wrote:
> What does this represent?
>
> unsigned int n : 6;

Your pitiful inability to consult a reference manual.

On 15 Apr 2008 at 2:04, robertwessel2@yahoo.com wrote:
> On Apr 14, 5:20Âpm, ymunt...@gmail.com wrote:
>> Almost assuredly, OP is not using a fancy apple or sun machine, true.
>> (That code most certainly needs gcc or gcc-compatible compiler,
>> but that's something almost assuredly used by OP, indirectly)
>
> The structure as presented would have *not* been correct on almost any
> x86 implementation (actually on none that I know of, and I frankly
> doubt there are any where it would have been).

Of course it's quite likely that the OP is using an x86, but it's not
the absolute certainty you're implying. I think the latest stats are
that 20% of laptop sales are Apples, and I imagine that C programmers
are disproportionately likely to be using interesting big-endian
hardware for their work...

On Apr 15, 2:49am, Antoninus Twink <nos...@nospam.invalid> wrote:
> On 15 Apr 2008 at 2:04, robertwess...@yahoo.com wrote:
>
> > On Apr 14, 5:20pm, ymunt...@gmail.com wrote:
> >> Almost assuredly, OP is not using a fancy apple or sun machine, true.
> >> (That code most certainly needs gcc or gcc-compatible compiler,
> >> but that's something almost assuredly used by OP, indirectly)
>
> > The structure as presented would have *not* been correct on almost any
> > x86 implementation (actually on none that I know of, and I frankly
> > doubt there are any where it would have been).
>
> Of course it's quite likely that the OP is using an x86, but it's not
> the absolute certainty you're implying. I think the latest stats are
> that 20% of laptop sales are Apples,


All of which are now x86. (Actually it's probable that Apple is still
moving a handful of PPC based systems to people who care more about
compatibility than price or performance).


> and I imagine that C programmers
> are disproportionately likely to be using interesting big-endian
> hardware for their work...


All of which are now x86. (Actually it's probable that Apple is still
moving a handful of PPC based systems to people who care more about
compatibility than price or performance).



True, but mostly as embedded gear. There are darn few primary
computing* systems that aren't x86 out there (and even fewer shipping
now), older PPC based Macs are probably the biggest population.


*Desktops, laptops, servers, HPC systems - IOW, non-embedded stuff

On Tue, 15 Apr 2008 00:31:21 -0700, Kaz Kylheku wrote:

> On Apr 12, 7:36am, saverio.p...@gmail.com wrote:
>> What does this represent?
>>
>> unsigned int n : 6;
>
> Your pitiful inability to consult a reference manual.

Given a "reference manual", where would you look it up?

--
ROT-13 email address to reply

Anand Hariharan <znvygb.nanaq.unevunena@tznvy.pbz> writes:

> On Tue, 15 Apr 2008 00:31:21 -0700, Kaz Kylheku wrote:
>
>> On Apr 12, 7:36Âam, saverio.p...@gmail.com wrote:
>>> What does this represent?
>>>
>>>     unsigned int n  : 6;
>>
>> Your pitiful inability to consult a reference manual.
>
> Given a "reference manual", where would you look it up?

Exactly. His reply would almost make me think he is Nick Keighley nym
shifting. But I'm sure that's where the similarities end ..

Anand Hariharan wrote:
> Kaz Kylheku wrote:
>> saverio.p...@gmail.com wrote:
>>
>>> What does this represent?
>>>
>>> unsigned int n : 6;
>>
>> Your pitiful inability to consult a reference manual.
>
> Given a "reference manual", where would you look it up?

Under "Declarations".

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

On Thu, 17 Apr 2008 00:09:40 -0400, CBFalconer wrote:

> Anand Hariharan wrote:
>> Kaz Kylheku wrote:
>>> saverio.p...@gmail.com wrote:
>>>
>>>> What does this represent?
>>>>
>>>> unsigned int n : 6;
>>>
>>> Your pitiful inability to consult a reference manual.
>>
>> Given a "reference manual", where would you look it up?
>
> Under "Declarations".
>

Looking up K&R2 index entry for "declaration", I see page references 9, 40
and 210-218.

Pages 9 and 40 do not discuss bit fields. Pages 210-218 gets into grammar,
and does not get into bit fields until mid-way of page 212. Not the
easiest of pages in this book to find the answer I sought out to find.

There are a dozen odd more entries for declaration, but nothing that says
"declaration, with colon" or something similar.

The entry for "declaration, structure" takes one to either page 128 or
212. Bit fields are covered in the same chapter as page 128, but it does
not come until page 150.

The index itself begins with entries for symbols starting from '0' to ...
'\0' (the quotes are mine), but no entry for ':'.

This isn't a critique of K&R2's index, but just to point out that it is
not obvious where to find an answer to OP's question. Considering that one
could always mouth off a rebuttal based on "reference manual" and
"consult", I suppose I am wasting my time ....

--
ROT-13 email address to reply

Anand Hariharan <znvygb.nanaq.unevunena@tznvy.pbz> wrote:
> On Tue, 15 Apr 2008 00:31:21 -0700, Kaz Kylheku wrote:
>
>> On Apr 12, 7:36 am, saverio.p...@gmail.com wrote:
>>> What does this represent?
>>>
>>> unsigned int n : 6;
>>
>> Your pitiful inability to consult a reference manual.
>
> Given a "reference manual", where would you look it up?

": (colon punctuator)" is in the Standard's index and points to exactly
the right place.

-Larry Jones

I think your train of thought is a runaway. -- Calvin's Mom

saverio.post@gmail.com wrote:

> What does this represent?
>
> unsigned int n : 6;
>
> ???

As shown this is a syntax error. Within a structure or union
declaration, this declares 'n' to be a "bit field" of 6 bits width and
of type unsigned int.

See:

<http://c-faq.com/struct/bitfield0.html>