This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: _Bool and trap representations
- From: Martin Sebor <msebor at gmail dot com>
- To: Alexander Cherepanov <ch3root at openwall dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 20 Jun 2016 13:27:59 -0600
- Subject: Re: _Bool and trap representations
- Authentication-results: sourceware.org; auth=none
- References: <5757BCD9 dot 9070407 at openwall dot com> <57582D90 dot 1080000 at gmail dot com> <575F0328 dot 7070905 at openwall dot com> <57616315 dot 40707 at gmail dot com> <57645B4B dot 4030207 at openwall dot com>
On 06/17/2016 02:19 PM, Alexander Cherepanov wrote:
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?
The standard says that padding bytes take on unspecified values
after an assignment to a structure, so the program isn't strictly
conforming because its output depends on such a value. At the
same time, unspecified values are, in general, expected to be
stable. But I think in this case it's only because of the
standard's limited vocabulary. The distinction between
an unspecified and undefined value was meant to allow for the
latter to be a trap representation. But lately an undefined
value has also come to mean potentially unstable (some people
call such values "wobbly"). If the standard adopted a term
for unspecified values that don't need not be stable (say
wobbly) I would expect the committee to be comfortable applying
it padding bits and allowing the code in the example to produce
two different lines. But this is one of the topics still under
active discussion.
Martin
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.