cast question, again

Alejandro Mery amery at geeks.cl
Sat Sep 27 15:47:31 CEST 2008


On Sat, Aug 30, 2008 at 8:08 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Fri, Aug 29, 2008 at 05:11:23PM +0200, Egon Eckert <egon.eckert at heaven-industries.com> wrote:
>> sorry about introducing the ever-appearing aliasing-warnings theme :)...  Can
>> someone, please, explain why *not* doing the cast in following macro
>> definition:
>
> not doing the cast accesses the "at" member of *ev (with unknown type, but
> usually the type isn't ev_watcher_time), doing the cast accesses the at
> member of the ev_watcher_time struct overlaying whatever ev's real type
> is.
>
> since all the remaining code also accesses the ev_watcher_time.at, leaving
> out the cast allows the compiler to reorder code because can assume they
> are not the same lvalues. (in practise, this doesn't happen between source
> files yet, but it does happen within the same source file).
>
> In c++, one could use an explicit static cast to typecheck, but not in C.
> (in c++, of course, one could simply subclass...)

I'm have this issue too, compiling my project with -Werror -Wall -W (by policy)
ev_timer_set(&self->timeout, 0.0, timeout); (same with _init)

with self.timeout been a "struct ev_timer"

leads to

warning: dereferencing type-punned pointer will break strict-aliasing rules

and compiling stops.. but

(&self->timeout)->at = 0.0;
(&self->timeout)->repeat = (timeout);

without the cast, compiles flawlessly.

there is any decent way to solve this?

Thanks,
Alejandro Mery



More information about the libev mailing list