Hi!

If a variable of type _Bool contains something different from 0 and 1 its use amounts to UB in gcc and clang. There is a couple of examples in [1] ([2] is also interesting).

[1] https://github.com/TrustInSoft/tis-interpreter/issues/39
[2] https://github.com/TrustInSoft/tis-interpreter/issues/100

But my question is about the following example:

----------------------------------------------------------------------
#include <stdio.h>

int main()
{
  _Bool b;
  *(char *)&b = 123;
  printf("%d\n", *(char *)&b);
}
----------------------------------------------------------------------

Results:

----------------------------------------------------------------------
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
123

$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
1
----------------------------------------------------------------------

gcc version: gcc (GCC) 7.0.0 20160604 (experimental)

It seems that padding in _Bool is treated as permanently unspecified. Is this behavior intentional? What's the theory behind it?

One possible explanations is C11, 6.2.6.2p1, which reads: "The values of any padding bits are unspecified." But it's somewhat a stretch to conclude from it that the values of padding bits cannot be specified even with explicit assignment.

Another possible approach is to refer to Committee Response for Question 1 in DR 260 which reads: "Values may have any bit-pattern that validly represents them and the implementation is free to move between alternate representations (for example, it may normalize pointers, floating-point representations etc.). [...] the actual bit-pattern may change without direct action of the program."

Is similar behavior expected from other types of padding (padding in long double, padding bytes/bits in structs/unions) in the future? Maybe even normalization of pointers (randomly aligning misaligned pointers)?

--
Alexander Cherepanov

Reply via email to