Re: _Bool and trap representations

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Jun 8, 2016 at 8:36 AM, Alexander Cherepanov
<ch3root@openwall.com> wrote:
> 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)?

Another explanation is that this is a bug.  It manifests itself at the time
we re-write 'b' into SSA form, disregarding the fact that we access it
via a type that while matching in size does not match in precision.

Can you open a bugreport?

Thanks,
Richard.

> --
> Alexander Cherepanov