Re: [PATCH] fix broken strict aliasing
On Thu, Feb 18, 2010 at 09:04:35PM +0600, Denis F. Latypoff de...@gostats.ru wrote: Hello Libev, The attached patch fixes broken strict aliasing in ev_timer_set() and ev_periodic_at() macros. the attached fix obviously doesn't fix anything, it just adds an unnecessary cast. maybe you should describe the problem you encountered or believe to have encountered? because if your an into an aliasing issue, then your patch will not fix it and at best hide it, making it rather dangerous. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On 19/02/10 18:22, Marc Lehmann wrote: On Thu, Feb 18, 2010 at 09:12:45PM +0600, Denis F. Latypoffde...@gostats.ru wrote: Just found yet another potentially broken strict aliasing rules in ev.c same here, this is at best a nop and at worst a dangerous patch. it has no effect on any aliasing issues you might have seen (obviously, as the types are still the same). what's the danger? why do you insist in refusing this? at best they reduce tons of warnings without affecting the code. what's wrong with the warnings? they add tons of noise that doesn't allow us to see clearly other warnings that can be interesting. Regards, Alejandro Mery smime.p7s Description: S/MIME Cryptographic Signature ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Fri, Feb 19, 2010 at 06:26:49PM +0100, Alejandro Mery am...@geeks.cl wrote: what's the danger? why do you insist in refusing this? a compiler might well find an aliasing issue with the existing code, but unlikely with the patch. at best they reduce tons of warnings without affecting the code. if you get tons of warnings then your compiler or config is broken, and this is certainly the exception. what's wrong with the warnings? good question, I don't get any warnings, and libev doesn't generate them. so you need to identify where the warnings originate (e..g in your compiler) and then ask this question to those people who actually control the code that generates such bogus warnings. they add tons of noise that doesn't allow us to see clearly other warnings that can be interesting. exactly... but this really is out of the scope for libev, as libev doesn't generate those warnings. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
Hi again,
On 19/02/10 18:39, Marc Lehmann wrote:
On Fri, Feb 19, 2010 at 06:26:49PM +0100, Alejandro Meryam...@geeks.cl wrote:
what's the danger? why do you insist in refusing this?
a compiler might well find an aliasing issue with the existing code, but
unlikely with the patch.
at best they reduce tons of warnings without affecting the code.
if you get tons of warnings then your compiler or config is broken, and this
is certainly the exception.
what's wrong with the warnings?
good question, I don't get any warnings, and libev doesn't generate them.
so you need to identify where the warnings originate (e..g in your
compiler) and then ask this question to those people who actually control
the code that generates such bogus warnings.
they add tons of noise that doesn't
allow us to see clearly other warnings that can be interesting.
exactly...
but this really is out of the scope for libev, as libev doesn't generate
those warnings.
ok, simple test case. (yes, it's only warnings, but they distract
a LOT)
$ grep -n ^ test.c
1:#include ev.h
2:#include stdio.h
3:
4:static void stdin_cb(struct ev_loop *loop, ev_io *w, int revents)
5:{
6: puts(stdin ready\n);
7: ev_io_stop(loop, w);
8: ev_unloop(loop, EVUNLOOP_ALL);
9:}
10:
11:int main(void)
12:{
13: struct ev_loop *loop = ev_default_loop(0);
14: ev_io stdin_watcher;
15:
16: ev_io_init(stdin_watcher, stdin_cb, 0, EV_READ);
17: ev_io_start(loop, stdin_watcher);
18:
19: ev_loop(loop, 0);
20:
21: return 0;
22:}
$ gcc -W -Wall -O2 -o test -lev test.c
test.c: In function ‘stdin_cb’:
test.c:4: warning: unused parameter ‘revents’
test.c: In function ‘main’:
test.c:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test.c:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test.c:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: warning: dereferencing pointer ‘stdin_watcher.22’ does
break strict-aliasing rules
test.c:16: note: initialized from here
$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Regards,
Alejandro Mery
smime.p7s
Description: S/MIME Cryptographic Signature
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On 02/19/2010 06:39 PM, Marc Lehmann wrote: what's wrong with the warnings? good question, I don't get any warnings, and libev doesn't generate them. so you need to identify where the warnings originate (e..g in your compiler) and then ask this question to those people who actually control the code that generates such bogus warnings. Are you _sure_ those are bogus? If you are using x86 with an ancient gcc you may not see them nor experience issues, any recent gcc on any recent arch will scream this way and with a reason... lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
