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 indetermin
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
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 du
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(&d0,
> "\x00\x00\x00\x00\x0
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(&d0,
"\x00\x00\x00\x00\x00\x00\x00\x00\xff\x3f\x00\x00\x00\x00\x00\x00", sizeof d0);
// d = d0;
m
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?
Ye
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
jos...@codesourcery.com
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
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 im
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] https://github.com/
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]
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:
>>>
>>> ---
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;
*(char *)&b = 123;
pri
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] https://github.com/TrustInSoft/tis-interpr
14 matches
Mail list logo
