--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-05
12:01 ---
> Reading your reply further, I understand that the behavior I observere is
> correct and related to the fact that the 'int32_t' type is assumed to be
> aligned.
Right.
> It is not a bug then, but merely
--- Additional Comments From maarten at contemplated dot nl 2005-05-05
11:56 ---
(In reply to comment #2)
Reading your reply further, I understand that the behavior I observere is
correct and related to the fact that the 'int32_t' type is assumed to be
aligned.
It is not a bug then,
--- Additional Comments From maarten at contemplated dot nl 2005-05-05
11:49 ---
(In reply to comment #2)
You are completely right, the code above merely demonstrates what happens when
one writes to an illegal address. The correct version,
*((int32_t *) &a.unaligned_int32) = 0x123456;
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-05
07:11 ---
I'm confused by this report. You use:
*((int32_t *) a.unaligned_int) = 0x123456;
which reads the value of a.unaligned_int, casts it from an integer
to a pointer, and then dereferences the pointer. W
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-04
19:10 ---
I think this is invalid because the standard talks about alignment and types.
--
What|Removed |Added
-
