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