How to merge two signed bit variables into one signed bit variable?

Question

Suppose the following c++ code:

#include <iostream>
using namespace std;

typedef struct 
{
       int a: 5;
       int b: 4;
  int c: 1;
  int d: 22;

} example;

int main()
{
example blah;

blah.a = -5; // 11011
blah.b = -3; // 1101

int result = blah.a << 4 | blah.b;

cout << "Result = " << result << endl; // equals 445 , but I am interested in this having a value of -67 

return 0;
}

I am interested in having the variable result be of type int where the 9th bit is the most significant bit. I would like this to be the case so that result = -67 instead of 445. How is this done? Thanks.

Answer 1

See Sign Extending an int in C for a closely related question (but not a duplicate).

You need to be aware that almost everything about bit fields is 'implementation defined'. In particular, it is not clear that you can assign negative numbers to a 'plain int' bit-field; you have to know whether your implementation uses 'plain int is signed' or 'plain int is unsigned'. Which is the 9^th bit gets tricky too; are you counting from 0 or 1, and which end of the set of bit-fields is at bit 0 and which at bit 31 (counting least significant bit (LSB) as bit 0 and most significant bit (MSB) as bit 31 of a 32-bit quantity). Indeed, the size of your structure need not be 32 bits; the compiler might have different rules for the layout.

With all those caveats out of the way, you have a 9-bit value formed from (blah.a << 4) | blah.b, and you want that sign-extended as if it was a 9-bit 2's complement number being promoted to (32-bit) int.

The function in the cross-referenced answer could do the job:

#include <assert.h>
#include <limits.h>

extern int getFieldSignExtended(int value, int hi, int lo);

enum { INT_BITS = CHAR_BIT * sizeof(int) };
int getFieldSignExtended(int value, int hi, int lo)
{
    assert(lo >= 0);
    assert(hi > lo);
    assert(hi < INT_BITS - 1);
    int bits = (value >> lo) & ((1 << (hi - lo + 1)) - 1);
    if (bits & (1 << (hi - lo)))
        return(bits | (~0 << (hi - lo)));
    else
        return(bits);
}

Invoke it as:

int result = getFieldSignExtended((blah.a << 4) | blah.b), 8, 0);

If you want to hard-wire the numbers, you can write:

int x = (blah.a << 4) | blah.b;

int result = (x & (1 << 8)) ? (x | (~0 << 8)) : x;

Note I'm assuming the 9^th bit is bit 8 of a value with bits 0..8 in it. Adjust if you have some other interpretation in mind.

---

Working code

Compiled with g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) from a RHEL 5 x86/64 machine.

#include <iostream>
using namespace std;

typedef struct 
{
    int a: 5;
    int b: 4;
    int c: 1;
    int d: 22;
} example;

int main()
{
    example blah;

    blah.a = -5; // 11011
    blah.b = -3; // 1101

    int result = blah.a << 4 | blah.b;

    cout << "Result = " << result << endl;

    int x = (blah.a << 4) | blah.b;
    cout << "x = " << x << endl;

    int result2 = (x & (1 << 8)) ? (x | (~0 << 8)) : x;
    cout << "Result2 = " << result2 << endl;

    return 0;
}

Sample output:

Result = 445
x = 445
Result2 = -67

---

ISO/IEC 14882:2011 — C++ Standard

§7.1.6.2 Simple type specifiers

¶3 ... [ Note: It is implementation-defined whether objects of char type and certain bit-fields (9.6) are represented as signed or unsigned quantities. The signed specifier forces char objects and bit-fields to be signed; it is redundant in other contexts. —end note ]

§9.6 Bit-fields [class.bit]

¶1 A member-declarator of the form

 identifier<sub>opt</sub> attribute-specifier-seq<sub>opt</sub>: constant-expression

specifies a bit-field; its length is set off from the bit-field name by a colon. The optional attribute-specifier-seq appertains to the entity being declared. The bit-field attribute is not part of the type of the class member. The constant-expression shall be an integral constant expression with a value greater than or equal to zero. The value of the integral constant expression may be larger than the number of bits in the object representation (3.9) of the bit-field’s type; in such cases the extra bits are used as padding bits and do not participate in the value representation (3.9) of the bit-field. Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit. [ Note: Bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. —end note ]

¶2 A declaration for a bit-field that omits the identifier declares an unnamed bit-field. Unnamed bit-fields are not members and cannot be initialized. [ Note: An unnamed bit-field is useful for padding to conform to externally-imposed layouts. —end note ] As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary. Only when declaring an unnamed bit-field may the value of the constant-expression be equal to zero.

¶3 A bit-field shall not be a static member. A bit-field shall have integral or enumeration type (3.9.1). It is implementation-defined whether a plain (neither explicitly signed nor unsigned) char, short, int, long, or long long bit-field is signed or unsigned. A bool value can successfully be stored in a bit-field of any nonzero size. The address-of operator & shall not be applied to a bit-field, so there are no pointers to bitfields. A non-const reference shall not be bound to a bit-field (8.5.3). [ Note: If the initializer for a reference of type const T& is an lvalue that refers to a bit-field, the reference is bound to a temporary initialized to hold the value of the bit-field; the reference is not bound to the bit-field directly. See 8.5.3. —end note ]

¶4 If the value true or false is stored into a bit-field of type bool of any size (including a one bit bit-field), the original bool value and the value of the bit-field shall compare equal. If the value of an enumerator is stored into a bit-field of the same enumeration type and the number of bits in the bit-field is large enough to hold all the values of that enumeration type (7.2), the original enumerator value and the value of the bit-field shall compare equal. [ Example:

enum BOOL { FALSE=0, TRUE=1 };
struct A {
    BOOL b:1;
};
A a;
void f() {
    a.b = TRUE;
    if (a.b == TRUE) // yields true
    { /* ... */ }
}

—end example ]

---

ISO/IEC 9899:2011 — C2011 Standard

The C standard has essentially the same effect, but the information is presented somewhat differently.

6.7.2.1 Structure and union specifiers

¶4 The expression that specifies the width of a bit-field shall be an integer constant expression with a nonnegative value that does not exceed the width of an object of the type that would be specified were the colon and expression omitted.¹²²⁾ If the value is zero, the declaration shall have no declarator.

¶5 A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type. It is implementation-defined whether atomic types are permitted.

¶9 ... In addition, a member may be declared to consist of a specified number of bits (including a sign bit, if any). Such a member is called a bit-field;¹²⁴⁾ its width is preceded by a colon.

¶10 A bit-field is interpreted as having a signed or unsigned integer type consisting of the specified number of bits.¹²⁵⁾ If the value 0 or 1 is stored into a nonzero-width bit-field of type _Bool, the value of the bit-field shall compare equal to the value stored; a _Bool bit-field has the semantics of a _Bool.

¶11 An implementation may allocate any addressable storage unit large enough to hold a bitfield. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.

¶12 A bit-field declaration with no declarator, but only a colon and a width, indicates an unnamed bit-field.¹²⁶⁾ As a special case, a bit-field structure member with a width of 0 indicates that no further bit-field is to be packed into the unit in which the previous bitfield, if any, was placed.

¹²²⁾ While the number of bits in a _Bool object is at least CHAR_BIT, the width (number of sign and value bits) of a _Bool may be just 1 bit.

¹²⁴⁾ The unary & (address-of) operator cannot be applied to a bit-field object; thus, there are no pointers to or arrays of bit-field objects.

¹²⁵⁾ As specified in 6.7.2 above, if the actual type specifier used is int or a typedef-name defined as int, then it is implementation-defined whether the bit-field is signed or unsigned.

¹²⁶⁾ An unnamed bit-field structure member is useful for padding to conform to externally imposed layouts.

Annex J of the standard defines Portability Issues, and §J.3 defines Implementation-defined Behaviour. In part, it says:

J.3.9 Structures, unions, enumerations, and bit-fields

¶1 — Whether a ‘‘plain’’ int bit-field is treated as a signed int bit-field or as an unsigned int bit-field (6.7.2, 6.7.2.1).

— Allowable bit-field types other than _Bool, signed int, and unsigned int (6.7.2.1).

— Whether atomic types are permitted for bit-fields (6.7.2.1).

— Whether a bit-field can straddle a storage-unit boundary (6.7.2.1).

— The order of allocation of bit-fields within a unit (6.7.2.1).