Re: [PATCH] configure.ac: fix syntax error in ./configure
On 11.12.2014 23:52, Marc Lehmann wrote: On Thu, Dec 11, 2014 at 06:16:57PM +0100, Alejandro Mery am...@geeks.cl wrote: ./configure: line 2815: syntax error near unexpected token `ac_config_headers=$ac_config_headers config.h' ./configure: line 2815: `fi ac_config_headers=$ac_config_headers config.h' I don't get this error, line 2815 is simply fi, which is correct. this is still a problem with autoconf 2.69 compiling libev-4.19 from sources AFAICS, libev-4.19 uses autoconf 2.50, not 2.69 (I just checked the release tarball) - it seems you have some kind of hacked libev - where did you download your version? The official place to get libev is here, btw., other download locations are not generally under my control. http://dist.schmorp.de/libev/ it's not a hacked libev, neither a tarball release. I'm using a git mirror of your CVS repository and then running autogen.sh. 2.69 is the version of autoconf on my laptop and build server. ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: A better way to deal with gcc's 'strict aliasing' warning
sorry for the noise... thunderbird decided to reorder the mails and I
didn't look at the date before replying :
On 15.12.2014 23:45, Alejandro Mery wrote:
On 30.07.2012 12:04, Jianbin Kang wrote:
Hello,
In `ev.h', the macro using (type of ev_watch *)(void *)(ev) to
convert `ev' to a required type.
The (void *) conversion may be used to supress gcc's 'strict
aliasing' warning (not sure).
This may work in previous version of gcc, but failed with gcc
4.7:
warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
The better way is to put all ev_watch type to an union (such as
union ev_any_watcher in ev.h),
and convert the pointer to (union ev_any_watch *).
For example, the following code can supress strict-aliasing
warning for macro 'ev_init':
typedef ev_any_watcher ev_any;
#define ev_init(ev,cb_) do {\
((ev_any *)(ev))-w.active =\
((ev_any *)(ev))-w.pending = 0; \
ev_set_priority ((ev), 0); \
ev_set_cb ((ev), cb_); \
} while (0)
# define ev_set_priority(ev,pri) ( (ev_any
*)(ev))-w.priority = (pri)
Is there any suggestion?
I usually reimplement ev_foo_init() macros the as static inline
functions with explicit types, and then everything goes smoothly.
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
[PATCH] configure.ac: fix syntax error in ./configure
dnl eats the new line between both statements ./configure: line 2815: syntax error near unexpected token `ac_config_headers=$ac_config_headers config.h' ./configure: line 2815: `fi ac_config_headers=$ac_config_headers config.h' this is still a problem with autoconf 2.69 compiling libev-4.19 from sources autoconf 2.69 on Ubuntu 14.04.1 LTS x86_64 thanks, Alejandro Mery --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 7e2d5e3..69e0c43 100644 --- a/configure.ac +++ b/configure.ac @@ -5,6 +5,7 @@ orig_CFLAGS=$CFLAGS AC_CONFIG_SRCDIR([ev_epoll.c]) AM_INIT_AUTOMAKE(libev,4.19) dnl also update ev.h! + AC_CONFIG_HEADERS([config.h]) AM_MAINTAINER_MODE -- 2.2.0 ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: exposing activecnt
On Wed, Nov 24, 2010 at 14:23, Zsbán Ambrus amb...@math.bme.hu wrote: On Wed, Nov 24, 2010 at 1:34 PM, Marc Lehmann schm...@schmorp.de wrote: The reason I believe that you don't need it is that ev_run already tells you that the count is 0 _by the act of returning_. That much works. But now suppose Ryan's program calls some finalizer, and possibly wants to know whether there are active watchers after that. He can recall ev_run, but does ev have a way of telling you whether it's returned immediately because there are no watchers? it smells like a return value for ev_run(), no? Regards, Alejandro Mery ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Example unix socket echo server
On Tue, Nov 2, 2010 at 08:41, Marc Lehmann schm...@schmorp.de wrote: On Mon, Nov 01, 2010 at 10:44:58PM -0600, AJ ONeal coola...@gmail.com wrote: The question that I have is if it's true to say that a unix socket is writable whenever it is readable? No, a unix domain socket works mostly like other stream sockets. When I tried listening for when it was writable, it seemed to fire the event over and over again. Do you have reason to assume that it was not writable over and over again? For it not to be writable you'd have to write enough data to fill it's buffers, and make sure nobody is reading on the other side. Or is it that when I want to send data I should start the watcher for writes send the data stop the watcher ? If you mean your write watcher was always active, then this explains your issue. Think about it, you ask libev when the socket is writable, but don't write anything. This means the socket will stay writable - there is no way for libev to know thta for some reason you are no longer interested in writability, except by stopping the watcher. A common (not necessarily most efficient) way to handle writes is: start the watcher in callback write more of the remaining data if all data has been written, stop the watcher kind of off-topic, but why send()/recv() instead of write()/read() ? ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Sat, Feb 20, 2010 at 16:01, Marc Lehmann schm...@schmorp.de wrote: On Fri, Feb 19, 2010 at 07:14:28PM +0100, Alejandro Mery am...@geeks.cl wrote: ok, simple test case. (yes, it's only warnings, but they distract a LOT) Really, this has nothing to do with libev - you found a buggy warning in your compiler, report this against your compiler, or switch it off. What's so difficult about it? Libev cannot and will not care about the many versions of compilers that generate bogus warnings, just as thousands of other software packages will not - this is an issue in your compiler, or your flags. Hello Marc, what compiler are you using? because gcc produces these warnings with every version since libev got born. Regards, Alejandro Mery ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH 2] fix broken strict aliasing
On Mon, Feb 22, 2010 at 16:11, Marc Lehmann schm...@schmorp.de wrote: On Mon, Feb 22, 2010 at 10:56:24AM +0100, Alejandro Mery am...@geeks.cl wrote: what compiler are you using? because gcc produces these warnings with every version since libev got born. gcc, and this is not true. so my sample code compiled for -O2 or higher or -Os doesn't dump the warning fest with your gcc version? I don't claim libev is buggy or that gcc is buggy, i simply say that the way that macro-magic is implemented confuses the compiler. it doesn't allow it to optimize correctly and who knows if it can trigger gcc-bugs, and also fills the compilation logs of our programs with tons of noise that doesn't allow libev users to see clearly real warnings/errors that do need to get fixed. so maybe those macros could be rewritten in a way that doesn't confuse the compilers and fill the compile log of noise just for the sake of the mental sanity of libev users? :) ___ 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
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: cast question, again
On Mon, Sep 29, 2008 at 3:58 AM, Marc Lehmann [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 02:00:20AM +0200, Alejandro Mery [EMAIL PROTECTED] wrote: I'm using -fno-strict-aliasing now to make gcc behave as a C compiler :) gcc tries to behave like a c compiler with or without that switch, that switch will not make any difference here. What you meant is that you made gcc accept your _buggy_, non-C code as if it were valid C, and try it's best to not misoptimise it, despite it having severe bugs. I know it's easy to deceive oneself, but the fact remains that your code is now buggy, thanks to the policy you are trying to follow. may I ask who's the buggy-code-maker from -Os -fno-strict-aliasing -Werror -Wall -W exactly? what do you suggest to add or remove to make gcc not produce buggy code? ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
