Re: [PATCH] manual: _Bool has trap representations

On Tue, 20 Sep 2016, Florian Weimer wrote: > On 09/19/2016 11:26 PM, Joseph Myers wrote: > > On powerpc-darwin _Bool is 4-byte not 1-byte, so saying values are > > represented as bytes isn't accurate for all systems supported by GCC. > > Interesting. > > Is the treatment of 0/1/the rest still

Re: [PATCH] manual: _Bool has trap representations

On 09/19/2016 11:26 PM, Joseph Myers wrote: On powerpc-darwin _Bool is 4-byte not 1-byte, so saying values are represented as bytes isn't accurate for all systems supported by GCC. Interesting. Is the treatment of 0/1/the rest still the same there? Thanks, Florian

Re: [PATCH] manual: _Bool has trap representations

On powerpc-darwin _Bool is 4-byte not 1-byte, so saying values are represented as bytes isn't accurate for all systems supported by GCC. -- Joseph S. Myers jos...@codesourcery.com

[PATCH] manual: _Bool has trap representations

Defined behavior for extraordinary values of _Bool would be preferable, but we can at least document what we have now. Thanks, Florian 2016-09-19 Florian Weimer <fwei...@redhat.com> * doc/implement-c.texi (Integers implementation): _Bool has trap representations.

Re: _Bool and trap representations

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

Re: _Bool and trap representations

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

Re: _Bool and trap representations

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

Re: _Bool and trap representations

On Wed, 15 Jun 2016, Bernd Edlinger wrote: > Hi, > > I modified Aexander's test case a bit, and found something > unexpected, which looks like a GCC-BUG to me: > > cat test.c > #include > #include > #include > > int main() > { > long double d0, d; > > memcpy(, >

Re: _Bool and trap representations

Hi, I modified Aexander's test case a bit, and found something unexpected, which looks like a GCC-BUG to me: cat test.c #include #include #include int main() { long double d0, d; memcpy(, "\x00\x00\x00\x00\x00\x00\x00\x00\xff\x3f\x00\x00\x00\x00\x00\x00", sizeof d0); // d = d0;

Re: _Bool and trap representations

On 2016-06-14 00:13, Joseph Myers wrote: On Tue, 14 Jun 2016, Alexander Cherepanov wrote: The problem is that parts of representations of two different ordinary values can form a trap representation. Oh, you're talking about normalizing the destination rather than the source of the copy?

Re: _Bool and trap representations

On Tue, 14 Jun 2016, Alexander Cherepanov wrote: > The problem is that parts of representations of two different ordinary values > can form a trap representation. Oh, you're talking about normalizing the destination rather than the source of the copy? -- Joseph S. Myers

Re: _Bool and trap representations

On 2016-06-13 22:51, Joseph Myers wrote: On Mon, 13 Jun 2016, Alexander Cherepanov wrote: Thanks for the info. IMHO this part of DR 260 has even more serious consequences than the part about pointer provenance. It effectively prohibits manual byte-by-byte (or any non-atomic) copying of objects

Re: _Bool and trap representations

On Mon, 13 Jun 2016, Alexander Cherepanov wrote: > Thanks for the info. IMHO this part of DR 260 has even more serious > consequences than the part about pointer provenance. It effectively prohibits > manual byte-by-byte (or any non-atomic) copying of objects for types like long > double. If an

Re: _Bool and trap representations

On 2016-06-08 17:37, Martin Sebor wrote: On 06/08/2016 12:36 AM, Alexander Cherepanov 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]

Re: _Bool and trap representations

On 06/08/2016 12:36 AM, Alexander Cherepanov 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]

Re: _Bool and trap representations

On Wed, Jun 8, 2016 at 10:04 AM, Alexander Cherepanov wrote: > On 2016-06-08 10:29, Richard Biener wrote: >> >> On Wed, Jun 8, 2016 at 8:36 AM, Alexander Cherepanov >> wrote: > > [skip] >>> >>> But my question is about the following example: >>> >>>

Re: _Bool and trap representations

On 2016-06-08 10:29, Richard Biener wrote: On Wed, Jun 8, 2016 at 8:36 AM, Alexander Cherepanov wrote: [skip] But my question is about the following example: -- #include int main() { _Bool b;

Re: _Bool and trap representations

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

_Bool and trap representations

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]