Re: _Bool and trap representations

[Alexander Cherepanov <ch3root at openwall dot com>]

On 2016-06-15 17:15, Martin Sebor wrote:
> > > There has been quite a bit of discussion among the committee on
> > > this subject lately (the last part is the subject of DR #451,
> > > though it's discussed in the context of uninitialized objects
> > > with indeterminate values).
> >
> > Are there notes from these discussions or something?
>
> Notes from discussions during committee meetings are in the meeting
> minutes that are posted along with other committee documents on the
> public site.   Those that relate to aspects of defect reports are
> usually captured in the Committee Discussion and Committee Response
> to the DR.  Other than that, committee discussions that take place
> on the committee mailing list (such as the recent ones on this topic)
> are archived for reference of committee members (unlike C++, the C
> archives are not intended to be open to the public).

So it seems the discussion you referred to is not public, that's 
unfortunate.

And to clarify what you wrote about stability of valid representations, 
is padding expected to be stable when it's not specifically set? I.e. is 
the following optimization supposed to be conforming or not?

Source code:

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

int main(int argc, char **argv)
{
  (void)argv;

  struct { char c; int i; } s = {0, 0};

  printf("%d\n", argc ? ((unsigned char *)&s)[1] : 5);
  printf("%d\n", argc ? ((unsigned char *)&s)[1] : 7);
}
----------------------------------------------------------------------

Results:

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

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

Of course, clang does essentially the same but the testcase is a bit 
more involved (I can post it if somebody is interested). OTOH clang is 
more predictable in this area because rules for dealing with undefined 
values in llvm are more-or-less documented -- 
http://llvm.org/docs/LangRef.html#undefined-values .

I don't see gcc treating padding in long double as indeterminate in the 
same way as in structs but clang seems to treat them equally.

--
Alexander Cherepanov