> 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 <[email protected]> wrote:
> On Fri, May 22, 2015 at 01:14:57AM -0700, Andrey Pokrovskiy
> <[email protected]> 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
> --==---/ / _ \/ // /\ \/ / [email protected]
> -=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
