size of bitfieds / strange warning

[stip]

I'm trying to use a struct type like the following:

struct Compact
{
unsigned short int j : 7;
unsigned long k : 56;
unsigned char type : 1;
};

Why does the compiler complain about the second component? On my
system long has 8 bytes, thus 56 bits should fit into it. But the
compiler complains:

warning: declared size for bit field is larger than the size of the
bit field type; truncated to 32 bits

How can I tell the compiler to allow 64 bits, i.e. long? Or is the
maximal single bitfield component 32 bits?

 

[Alf P. Steinbach /Usenet]

* stip, on 01.02.2011 11:05:

I'm trying to use a struct type like the following:

struct Compact
{
unsigned short int j : 7;
unsigned long k : 56;
unsigned char type : 1;
};

Why does the compiler complain about the second component? On my
system long has 8 bytes, thus 56 bits should fit into it.

This seems to be your opinion.

But the
compiler complains:

warning: declared size for bit field is larger than the size of the
bit field type; truncated to 32 bits

This seems to be reality.

How can I tell the compiler to allow 64 bits, i.e. long? Or is the
maximal single bitfield component 32 bits?

Use C++0x 'long long' type.


Cheers & hth.,

- Alf

 

[stip]

* stip, on 01.02.2011 11:05:




This seems to be your opinion.

It is my opinion and sizeof(long) yields 8, thus it's a tested
opinion.

This seems to be reality.

And what's the reason for this reality?

Use C++0x 'long long' type.

This doesn't change the result.

 

[Saeed Amrollahi]

I'm trying to use a struct type like the following:

struct Compact
{
    unsigned short int j : 7;
    unsigned long      k : 56;
    unsigned char   type : 1;

};

Why does the compiler complain about the second component? On my
system long has 8 bytes, thus 56 bits should fit into it. But the
compiler complains:

warning: declared size for bit field is larger than the size of the
bit field type; truncated to 32 bits

How can I tell the compiler to allow 64 bits, i.e. long? Or is the
maximal single bitfield component 32 bits?

Hi

I tested your program with GCC 4.5.0. Because, the size of long
is equal to size of int, so, I used the type long long, which
was added to C++0x. Your program is OK. No error, no warning.
Which software/hardware platform and programming environment
you use?

Regards,
-- Saeed Amrollahi

 

[stip]

Hi

I tested your program with GCC 4.5.0. Because, the size of long
is equal to size of int, so, I used the type long long, which
was added to C++0x. Your program is OK. No error, no warning.
Which software/hardware platform and programming environment
you use?

Regards,
  -- Saeed Amrollahi

Thanks for checking this.
If I use long long instead of long I get no warning too.
Nevertheless the value of Compact.k is truncated to 32 bits. It's not
just the warning, the problem is the behaviour of the program.

Regards,
Alex

 

[Alf P. Steinbach /Usenet]

* stip, on 01.02.2011 12:24:

It is my opinion and sizeof(long) yields 8, thus it's a tested
opinion.


And what's the reason for this reality?


This doesn't change the result.

Else-thread you're saying that it does get rid of the warning.

And you fail to specify which compiler.

You sound confused, possibly trolling.


- Alf

 

[stip]

* stip, on 01.02.2011 12:24:









Else-thread you're saying that it does get rid of the warning.

And you fail to specify which compiler.

You sound confused, possibly trolling.

- Alf

Re-Read your first answer to my question and you find yourself
possibly trolling. Instead of trying to help, you just give answers,
well to say it positive, which are not helpful at all.
I said I got rid of the warning by replacing long by long long, but
the value was still truncated. So the focus changed (independent of
the compiler version). But you're right, indeed I forgot to mention
the compiler. And the behavior is not specific to just one compiler
version but occurs for gcc (4.0, 4.4.2), icc (11.1).
In the meanwhile another question seems much more important to me,
i.e. if the code is at all legal. Because the struct inside the union
is anonymous. I fear that's not in the standard. The compilers I used
do not complain, but that's not satisfying as answer.

Alex

 

[Alf P. Steinbach /Usenet]

* stip, on 01.02.2011 15:04:[snip quoted signature]
[snip

Re-Read your first answer to my question and you find yourself
possibly trolling. Instead of trying to help, you just give answers,

Are you, by any chance, seriously sleep-deprived?

You **do not** want answers?

well to say it positive, which are not helpful at all.

So using 'long long' didn't help at all?

But it did get rid of your warning?

Again, are you seriously sleep-deprived?

I said I got rid of the warning by replacing long by long long, but
the value was still truncated. So the focus changed (independent of
the compiler version). But you're right, indeed I forgot to mention
the compiler. And the behavior is not specific to just one compiler
version but occurs for gcc (4.0, 4.4.2), icc (11.1).

Here you forget to mention which OS.

For example, "long" is 32-bits for gcc under Windows, while you are claiming
that with your compiler it's 64-bits.

Are you sleep-deprived?

In the meanwhile another question seems much more important to me,
i.e. if the code is at all legal. Because the struct inside the union
is anonymous.

You haven't mentioned any union before now. First we should guess compiler, now
we should guess the OS, and finally we'll be left guessing at the code that's
wrong, the code you haven't shown and that is in error.

Note well:


*** Readers are NOT telepaths ***


Readers of your postings, like me, can not actually "see" the code in front of you.

How about some sleep?

I fear that's not in the standard. The compilers I used
do not complain, but that's not satisfying as answer.

Should be OK, but can't say without the code.

Here's code that should work with any compiler that supports "long long":


struct Compact
{
unsigned short j : 7;
unsigned long long k : 56;
unsigned char type : 1;
};

#include <iostream>
using namespace std;
int main()
{
Compact o = { 101, 1ull << 55, 1 };

cout << hex;
cout << o.j << "\n" << o.k << "\n" << o.type+0 << "\n";
}


Cheers & hth.,

- Alf

 

[Michael Tsang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I tested your program with GCC 4.5.0. Because, the size of long
is equal to size of int, so, I used the type long long, which
was added to C++0x. Your program is OK. No error, no warning.
Which software/hardware platform and programming environment
you use?

A GCC long is 64-bit on 64-bit systems but 32-bit on 32-bit systems
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1IK0AACgkQZ1Turg5KUCmYcACfQeaig+4MgSxpS1zHilQBUYbS
6lgAoIyTenNVRSko8UhZwKSYDVU5Z2Rc
=AA0O
-----END PGP SIGNATURE-----

 

[Paul]

* stip, on 01.02.2011 15:04:

<snip>
Alf you are being a complete arsehole.
As usual

 

[Lars Tetzlaff]

Am 01.02.2011 16:48, schrieb Michael Tsang:

A GCC long is 64-bit on 64-bit systems but 32-bit on 32-bit systems

IMHO it depends on the OS: Windows 64 is LLP64 whereas Linux/Unix is
LP64 (http://en.wikipedia.org/wiki/LLP64)

Lars

 

[Jorgen Grahn]

I'm trying to use a struct type like the following:

struct Compact
{
unsigned short int j : 7;
unsigned long k : 56;
unsigned char type : 1;
};

Why does the compiler complain about the second component? On my
system long has 8 bytes, thus 56 bits should fit into it. But the
compiler complains:

warning: declared size for bit field is larger than the size of the
bit field type; truncated to 32 bits

How can I tell the compiler to allow 64 bits, i.e. long? Or is the
maximal single bitfield component 32 bits?

Bitfields make me nervous. I haven't used them for ages.

Since 7+56+1 == 64 I suspect this maps to an uint64_t somewhere in
your design. I suggest just wrapping a uint64_t in struct Compact and
provide member functions to mess with the three parts as needed. I bet
that would be just as fast with inlining and all, and almost as easy
to use. And, it works ;-)

/Jorgen

 

[James Kanze]

Am 01.02.2011 16:48, schrieb Michael Tsang:

IMHO it depends on the OS: Windows 64 is LLP64 whereas Linux/Unix is
LP64 (http://en.wikipedia.org/wiki/LLP64)

The final choice is in the compiler; it decides how it will lay
something out. In practice, however, no compiler will go
against the layouts (sizes, padding, etc.) used by the OS in its
API, since otherwise, you couldn't use the API in code compiled
by the compiler.