Contact Us

Home > Error Type > Error Type Of Bit-field Is A Gcc Extension

Error Type Of Bit-field Is A Gcc Extension

We then turned on "-Wconversion" only to discover thousands of warnings with no way practical way to fix them. We need to move to a more recent version of gcc, but are still stuck at gcc 4.2.4. It's a bad hack. > Really? Sign Up Now! check over here

You signed in with another tab or window. Comment 8 Zachary Deretsky 2010-02-18 20:50:00 UTC With -Wconversion for the assignment to bitfields gcc 4.4.2 gives a warning, which is impossible to fix. dspfun Guest Hi, I want to use bit-fields in unsigned short types since it makes code a lot easier to read and I don't have to do bit-masks and bit-shifts to I think the two behaviors are orthogonal.

Until the "C" or "C++" language contains a "type-safe" construct, such as a cast-operator, "gcc" should not issue a warning by default. And there is no "language" defined way to eliminate this warning. Comment 11 Manuel López-Ibáñez 2010-03-06 12:18:43 UTC (In reply to comment #10) > However, with so many lines of legacy code out there using bit-filed that have > been proven to buffer[0] = ihl*16+version; buffer[1] = tos; buffer[2] = tot_len/256; buffer[3] = tot_len%256; // etc.

Just an FYI, there's a proposal to add a -Wbitfield-conversion flag that does something slightly different than the behavior described in this issue; for reference, see: I'd be fine with We upgraded from 3.4.6 to 4.2/4.3. Ben Bacarisse, Mar 9, 2011 #2 Advertisements dspfun Guest On 9 mar, 10:40, Ben Bacarisse <> wrote: > What advantage do you hope to get from using unsigned short rather than I don't care what "-Wconversion" previously did.

g++ did warn but not with -Wall, > you still needed to specify -Wconversion, and it did not warn in many cases. To access the information in the > two bytes I declare a struct with bit-fields. We need the compiler to issue warnings when implicit narrowing occurs (expect in the case of a bit-field). As a result, you cannot portably rely upon the bits from the data you're transferring being in the same location as the bits corresponding to any particular bit field.

Expect for bit-fields which are problematic to do potential bit-loss (you must use with caution), you want warnings for implicit narrowing if values, e.g., (double -> int) void foo( int x We've already moved back to the 4.2 "gcc". There is nothing in the "C++" > standard (that I'm aware of) that suggests that "anding" an integral value with > a "constant" value results in a truncated integral value. References: [Wireshark-dev] Making gcc less pedantic From: Gerald Combs Prev by Date: Re: [Wireshark-dev] Failed to build wireshark 1.99.2 under OpenSUSE 11.4 (x86_64) Next by Date: [Wireshark-dev] How do you start

The change of behaviour was documented beyond what is normally expected. > We can fault ourselves for missing this change in the documentation, but there > a level of expectation that It makes the compiler (for us) not usable. > Of course it doesn't. I have succesfully compiled freeswitch with the latest revision. We no get thousands of warning using -Wconversion, this behavior makes the option useless.

If portability isn't an issue, then there's no problem; but for maximally portable code, your best option is to use a unsigned char buffer, and extracting the bits by using shift Are you open to silencing them by GCC diagnostic pragmas? #pragma GCC diagnostic ignored "-Wpedantic" unsigned long pad:4; /**< number of octets used for padding after adresses. */ unsigned long reserved:20; The only way "C" or "C++" to assign a integral variable a bit field is an assignment: struct A { unsigned int v : 2; } void foo( A * a, Do you mena that you're extracting individual bits from the unsigned short member?

Comment 15 Manuel López-Ibáñez 2015-03-06 20:10:40 UTC (In reply to Eric Gallager from comment #14) > Just an FYI, there's a proposal to add a -Wbitfield-conversion flag that > does something In 3.4.6, gcc warned of this error without any additional options. > Fixing bugs alters behaviour. As you say, its is unfortunate that "C" and "C++" do not have a bit-field "cast-operators". this content Brs, Markus dspfun, Mar 11, 2011 #17 Ben Pfaff Guest dspfun <> writes: > On 11 mar, 17:07, Keith Thompson <> wrote: > >> As several people have mentioned, the

A bit-field is interpreted as an integral type consisting of the specified number of bits. Personally, I have no free time to work on this, so someone else will have to do it. Your name or email address: Do you already have an account?

C90 says A bit-field shall have a type that is a qualified or unqualified version of one of int, unsigned int, or signed int.

Which means that the values for the 1-bit sized integer are 0 and -1. And this is not acceptable to us. Infinite sum of logs puzzle Meaning of S. Stay logged in Welcome to The Coding Forums!

In any case, someone else would need to > take care of this because I do not have time. > > I don't understand why this change was made when The easy recipe: For the assignment to bit-fileds use unsigned int bit-field on the left and mask the right side with the appropriate mask. ***2. Newer Than: Search this thread only Search this forum only Display results as threads Useful Searches Recent Posts More... have a peek at these guys I don't see this change as a bug-fix.

I looked at gcc 4.7.2 but behavior is the same and I don't see an option to suppress these warnings. When looking > briefly at the Linux IP-stack it appears to be using bit-fields for, > for example, the IP-header.