4 ms·

> you should check your compiler's behavior There is one thing I have noticed in gcc and clang which is done against the standards: The sign of bit sized int i

by pksadiq 10y ago

> you should check your compiler's behavior There is one thing I have noticed in gcc and clang which is done against the standards: The sign of bit sized int in a struct. eg: In a struct with member 'int a:8', The standard says that 'a' can be signed or unsigned (based on the machines default of the sign of char). But In gcc and clang, this is signed always regardless of the machine.

ygra 10y ago
Similarly, msvc guarantees signed overflow, it's not UB when targeting only that compiler. And gcc/clang have a compiler switch to do the same, I believe. Those things are probably what they meant when they said to look at what the compiler does.
lmm 10y ago
> eg: In a struct with member 'int a:8', The standard says that 'a' can be signed or unsigned (based on the machines default of the sign of char). But In gcc and clang, this is signed always regardless of the machine. Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not?
- pksadiq 10y ago
  > Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not? It's permitted. The same way as a char can be signed or unsigned: Implementation defined. But in this case, it's always signed regardless of the architecture (against how a char is handled). From c99 draft (n1570), J.3.9 (Implementation-defined behavior): 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). But say, another compiler (ARM compiler) treats this differently [0]: Untill version 5 of the compiler, such an int was unsigned by default. Later versions defaulted to signed (as do gcc/clang). [0] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15377.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....

4 ms·

> you should check your compiler's behavior There is one thing I have noticed in gcc and clang which is done against the standards: The sign of bit sized int i

by pksadiq 10y ago

ygra 10y ago
Similarly, msvc guarantees signed overflow, it's not UB when targeting only that compiler. And gcc/clang have a compiler switch to do the same, I believe. Those things are probably what they meant when they said to look at what the compiler does.
lmm 10y ago
> eg: In a struct with member 'int a:8', The standard says that 'a' can be signed or unsigned (based on the machines default of the sign of char). But In gcc and clang, this is signed always regardless of the machine. Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not?
- pksadiq 10y ago
  > Wait, are you saying gcc/clang's behaviour is permitted by the standard, or not? It's permitted. The same way as a char can be signed or unsigned: Implementation defined. But in this case, it's always signed regardless of the architecture (against how a char is handled). From c99 draft (n1570), J.3.9 (Implementation-defined behavior): 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). But say, another compiler (ARM compiler) treats this differently [0]: Untill version 5 of the compiler, such an int was unsigned by default. Later versions defaulted to signed (as do gcc/clang). [0] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15377.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....