Strict aliasing rule strikes back

Andrey Pokrovskiy wonder.mice at gmail.com
Sat May 23 02:20:39 CEST 2015


> the additional void * cast is there to confuse some compilers
> into not emitting a warning, but is generally not very effective.

Reminds me of "security through obscurity".

Btw, for those who also suffer from those GCC warnings I end up with
adding the following to our cflags.cmake:

if(CMAKE_C_COMPILER_VERSION MATCHES "4.9.2")
    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wno-strict-aliasing")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-strict-aliasing")
endif()

We use clang as our main compiler, and need GCC only to cross-compile
for different platforms. Also signal to noise ratio of aliasing
analysis implementation in GCC definitely "could be improved". And
explicit GCC version check will allow to reexamine this override later
for new GCC releases.

On Fri, May 22, 2015 at 4:48 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Fri, May 22, 2015 at 01:14:57AM -0700, Andrey Pokrovskiy <wonder.mice at gmail.com> wrote:
>> > so all accesss have to be against the ev_watcher struct, everywhere
>>
>> So you are saying, that libev needs "(ev_watcher *)(void *)" cast
>> exactly because it uses such cast (ev_watcher * type to be more
>> precise) everywhere to access those members. And by uniformly
>
> It needs the ev_watcher * cast, the additional void * cast is there to
> confuse some compilers into not emitting a warning, but is generally not
> very effective.
>
> Otherwise, yes, the cast is so we access these members _always_ as
> ev_watcher member, both inside libev, and in user code.
>
> --
>                 The choice of a       Deliantra, the free code+content MORPG
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list