On Wed, Jun 8, 2016 at 8:36 AM, Alexander Cherepanov <ch3r...@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
