|ARM Technical Support Knowledge Articles|
Consider the following structure that contains a single bit-field:
return (data.m_offset != -1);
Building the C program as follows:
armcc -c test.c (defaulting to optimization level
... results in the following code (translated by using
fromelf -c test.o):
0x00000000: e3a00001 .... MOV r0,#1
0x00000004: e12fff1e ../. BX lr
The test that
data.m_offset is not equal to minus one always holds true (#1) because the bit-field is treated as
unsigned by default.
If the code is changed so that the number that
data.m_offset is tested against is a positive number, for example:
return (data.m_offset != 0x7fffffff);
... the resultant disassembly listing is as one might expect:
0x00000008: e59f0010 .... LDR r0,[pc,#16] ; [0x20] = 0
0x0000000c: e3e01102 .... MVN r1,#0x80000000
0x00000010: e5900000 .... LDR r0,[r0,#0]
0x00000014: e1d10000 .... BICS r0,r1,r0
0x00000018: 13a00001 .... MOVNE r0,#1
0x0000001c: e12fff1e ../. BX lr
0x00000020: 00000000 .... DCD 0
The C Standard specifies that if the type specifier used in declaring a bit-field is either int, then whether the bit-field is
unsigned is dependent on the implementation.
In the ARM Compiler toolchain, a plain bit-field declared without the
unsigned qualifiers, is treated as
unsigned. In the example above, the bit-field
int m_offset: 31 is an unsigned int bit-field by default.
If you require integer bit-fields to be treated as signed int bit-fields, two possible solutions are given below:
signed int m_offset:31;
Use the compiler option
--unsigned_bitfields to make bitfields of type
signed int or
unsigned int. For further information, please see the ARM Compiler toolchain - Compiler Reference.
Did you find this article helpful? Yes No
How can we improve this article?