Re: Re: Weird strict-aliasing break

[Thibault Castel <thibault dot castel at gmail dot com>]

> ---------- Message transfÃrà ----------
> From:ÂSteffen Dettmer <steffen.dettmer@googlemail.com>
> To:Âgcc-help@gcc.gnu.org
> Date:ÂMon, 30 May 2011 13:59:51 +0200
> Subject:ÂRe: Weird strict-aliasing break
> On Mon, May 30, 2011 Thibault Castel <thibault.castel@gmail.com> wrote:
>> I have a weird warning when compiling my program with g++:
>> Â "dereferencing pointer âNAMEâ does break strict-aliasing rules"
>>
>> So, I tried to investigate a little bit and find some clues : I do a
>> memory mapping from a char buffer to a C struct to have access to
>> different datas into the buffer. Pretty casual. But, when I try to
>> access one of my inner field, the warning triggers... Huh...
>
> Beside that this may have other disadvantages, such as depending
> on byte order, padding and alighnment issues, in general you
> cannot assume that constructions like:
>
> struct s {
> Â int a; // or int32_t
> };
> char buffer[];
>
> struct s *p = buffer; Â p->a;
> struct s *p = buffer+1; p->a;
>
> this even may crash (we had such problems on some ARM CPUs).
>

Yes, we have some ARM CPUs as targets but specific code (with such
aligment adaptations) are used. The code I provided is x86 targeted
only ;)

> I think better here is using memcpy, but still "you have to know
> what you are doing".

No, because I don't want to copy anything. I just need to access
fields for reading and extracting data. I don't write into it. It's
really just a memory mapping.

>
> I think the only 100% correct way is proper deserialisation, maybe this way:
>
> struct s *p = new struct s;
> p->a =
> Â Â Â(int)(buffer[0]) * 0x1000000 +
> Â Â Â(int)(buffer[1]) * 0x0010000 +
> Â Â Â(int)(buffer[2]) * 0x0000100 +
> Â Â Â(int)(buffer[3]);
>
> A better workaround for the alignment probably could be something like:
>
> struct s {
> Â int a; // or int32_t
> };
> char buffer[];
>
> union x {
> Â Âstruct s;
> Â Âchar buffer[1];
> }
>
>> I successfully avoid the warning with "__attribute__((__may_alias__))"
>> but this "cheat" bother me because :
> - you might have a case where it breaks things
> Â(such as optimization changes behavior)
>
> I hope some expert corrects me where I'm wrong.

I don't like this directive. If I can avoid it, it would be great.

>
> oki,
>
> Steffen

Thanks