Re: Warnings from gcc
On Fri, Dec 21, 2007 at 05:18:56PM -0500, Jeff Squyres <[EMAIL PROTECTED]> wrote: > libev that was configured with "./configure CFLAGS='-Wall - > pedantic'" (or even just -Wall). I didn't compare closely, but I see Read the documentation on -pedantic. I know you don't like reading documentation, but it is sure worth it. Also, compiling with -pedantic is not supported, as we will freely use gcc extensions when gcc is available (even if it might compile), which is not possible with -pedantic (pedantic is *not* a sensible warning option, but best read the gcc docs). > Before analyzing these any further, do you care? No. Warnings are warnings, and every compiler has different ones and different tastes. If you know how to silence those warnings a) without introducing slowdowns and b) on every compiler, then I would like to hear about them. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Warnings from gcc
On Dec 22, 2007, at 5:31 AM, Marc Lehmann wrote:
No. Warnings are warnings, and every compiler has different ones and
different tastes. If you know how to silence those warnings a) without
introducing slowdowns and b) on every compiler, then I would like to
hear
about them.
Here's some pretty minor changes (both inline and attached; my mail
client tends to bork inline patch formatting):
1. Only instantiate the have_monotonic variable #if EV_USE_MONOTONIC
(have_monotonic's usage seems to be protected by EV_USE_MONOTONIC)
2. Only declare infy_fork() #if EV_USE_INOTIFY (infy_fork()'s
definition is surrounded by #if EV_USE_INOTIFY)
One more issue that I was not sure about: in ev.h, when
EV_MULTIPLICITY, ev_default_loop() is defined as:
static struct ev_loop *
ev_default_loop (unsigned int flags) { ... }
Should that function be marked as inline? That might result in a
slight speedup on some platforms if the function is actually inlined.
Additionally, it would remove a -Wall warning about ev_default_loop()
being defined but not used in files that don't call it. Same goes for
ev_now() in the !EV_MULTIPLICITY case.
Thanks.
--
Jeff Squyres
Cisco Systems
Index: ev.c
===
RCS file: /schmorpforge/libev/ev.c,v
retrieving revision 1.195
diff -u -r1.195 ev.c
--- ev.c22 Dec 2007 11:44:51 - 1.195
+++ ev.c22 Dec 2007 12:39:05 -
@@ -284,7 +284,9 @@
/* sig_atomic_t is used to avoid per-thread variables or locking but
still */
/* giving it a reasonably high chance of working on typical
architetcures */
+#if EV_USE_MONOTONIC
static sig_atomic_t have_monotonic; /* did clock_gettime
(CLOCK_MONOTONIC) work
? */
+#endif
#ifdef _WIN32
# include "ev_win32.c"
@@ -1119,7 +1121,9 @@
backend = 0;
}
+#if EV_USE_INOTIFY
void inline_size infy_fork (EV_P);
+#endif
void inline_size
loop_fork (EV_P)
libev-monotonic-infy-fork.patch
Description: Binary data
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Warnings from gcc
On Sat, Dec 22, 2007 at 08:28:50AM -0500, Jeff Squyres <[EMAIL PROTECTED]>
wrote:
> 1. Only instantiate the have_monotonic variable #if EV_USE_MONOTONIC
> (have_monotonic's usage seems to be protected by EV_USE_MONOTONIC)
>
> 2. Only declare infy_fork() #if EV_USE_INOTIFY (infy_fork()'s
> definition is surrounded by #if EV_USE_INOTIFY)
I think these changes increase maintainance burden too much without
providing any real benefit. Not having have_monotonic is an exceptional
case, and having to maintain #ifdef logic for it probably creates more
problems than it solves.
> static struct ev_loop *
> ev_default_loop (unsigned int flags) { ... }
>
> Should that function be marked as inline?
No, because inline semantics are not portable at the moment (C99 vs. gcc),
so static is the closest equivalent.
> That might result in a slight speedup on some platforms if the function
> is actually inlined.
Only if it wouldn't get inlined already, which it will be in most
cases. Have you actually looked? It would be interesting to know which
compiler doesn't inline it under whcih conditions (obviously, gcc without
optimisation won't).
> Additionally, it would remove a -Wall warning about ev_default_loop()
> being defined but not used in files that don't call it.
Making the code unportable to silence an optional warning in a compiler is
not really sensible, IMnsHO.
In general, you should NOT optimise for warnings, often this will result
in buggy or unportable code, and in many cases in harder to maintain code.
libev has been checked for relevant compiler warnings (on the platforms
and with the compilers I use only of course).
> Same goes for ev_now() in the !EV_MULTIPLICITY case.
Same reasoning here.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev 2.0 has been released
I just released libev 2.0 Distribution: http://dist.schmorp.de/libev/ Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod Changelog: http://cvs.schmorp.de/EV/Changes The 2.0 version bump is caused by major API changes in the Perl module, the actual libev changes are mostly evolutionary. Changes include: - documentation on speed and portability hints has been majorly improved. - embed watchers actually work now (subject to platform limitations). this caused an ABI and API change. - epoll has been declassified as non-embeddable (it doesn't work as documented). - there are three new functions: ev_set_io_collect_interval ev_set_timeout_collect_interval ^ these influence waiting and blocking times, which cna greatly influence the efficiency of servers at the expense of latency. ev_sleep ^ fallout from implementing the previous functions) - Symbol lists have been added that list all global symbols of the ev and event modules. - the namespace is now cleaner after including ev.c (rarely an issue). enjoy, and thanks to those poeple who helped (yes, even sending typo lists for the manpage helps :)! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Warnings from gcc
On Dec 22, 2007, at 10:31 AM, Marc Lehmann wrote:
>> 1. Only instantiate the have_monotonic variable #if EV_USE_MONOTONIC
>> (have_monotonic's usage seems to be protected by EV_USE_MONOTONIC)
>>
>> 2. Only declare infy_fork() #if EV_USE_INOTIFY (infy_fork()'s
>> definition is surrounded by #if EV_USE_INOTIFY)
>
> I think these changes increase maintainance burden too much without
> providing any real benefit. Not having have_monotonic is an
> exceptional
> case, and having to maintain #ifdef logic for it probably creates more
> problems than it solves.
2 "FWIW" points:
1. Not having have_monotonic is the default on OS X / Leopard (see
below)
2. #if's for EV_USE_MONOTONIC and EV_USE_INOTIFY already protect all
the usage of have_monotonic and inotify, respectively
>> static struct ev_loop *
>> ev_default_loop (unsigned int flags) { ... }
>>
>> Should that function be marked as inline?
>
> No, because inline semantics are not portable at the moment (C99 vs.
> gcc),
> so static is the closest equivalent.
Also FWIW: AC_C_INLINE can take of this for you -- here's its
description:
-
If the C compiler supports the keyword inline, do nothing. Otherwise
define inline to __inline__ or __inline if it accepts one of those,
otherwise define inline to be empty.
-
>> That might result in a slight speedup on some platforms if the
>> function
>> is actually inlined.
>
> Only if it wouldn't get inlined already, which it will be in most
> cases. Have you actually looked? It would be interesting to know which
> compiler doesn't inline it under whcih conditions (obviously, gcc
> without
> optimisation won't).
Nope; I didn't check.
> libev has been checked for relevant compiler warnings (on the
> platforms
> and with the compilers I use only of course).
Fair enough. Is OS X one of those platforms? (I couldn't find an
official list of supported platforms -- did I miss it?)
A related (but probably random) question: are there any correctness
tests for libev? I already run a boatload of regression tests for my
own stuff every night in an automated test harness; I'd be happy to
add libev (standalone; outside of the other stuff I test) to the mix
with a variety of platforms and compilers if it would be helpful.
--
Jeff Squyres
Cisco Systems
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Warnings from gcc
On Sat, Dec 22, 2007 at 06:18:12PM -0500, Jeff Squyres <[EMAIL PROTECTED]>
wrote:
> >>static struct ev_loop *
> >>ev_default_loop (unsigned int flags) { ... }
> >>
> >>Should that function be marked as inline?
> >
> >No, because inline semantics are not portable at the moment (C99 vs.
> >gcc),
> >so static is the closest equivalent.
>
> Also FWIW: AC_C_INLINE can take of this for you -- here's its
> description:
Jeff, please read what I wrote. You do not understand what inline means
and how C compilers generally work. I do not see how AC_C_INLINE is
relevant, as it doesn't tell me about inline _semantics_ and how to use
it, and it requires autoconf. Also, the current code and semantics are
*correct* and the wanted ones, and not using the inline function might
generate a warning as well, so silencing it in gcc is of little value.
If you are concerned, do not use -Wall in production builds (using -Wall
is basically a mistake in production builds as it includes an unknown,
often changing and sometimes broken set of warnings that will only scare
users). Please do not think that a warning indicates any problem with the
code whatsoever.
Because of our communications history, wouldn't it be possible to
"send" an actual developer who knows C and portability a bit? It is a
bit tiresome to have to explain C keywords and unix functions to you,
especially as portability issues require some experience, and my patience
admittedly has worn out a bit.
(Questions are ok, but if you do not like my answer because it doesn't
make sense to you you should first clarify it).
> >libev has been checked for relevant compiler warnings (on the
> >platforms
> >and with the compilers I use only of course).
>
> Fair enough. Is OS X one of those platforms? (I couldn't find an
> official list of supported platforms -- did I miss it?)
OS X is not one of those, but since afaics only gcc is used the warnings
should be comparable to similar platforms.
The list of official platforms is:
- POSIX (all)
- Winsockets (Windows 2000+, maybe earlier)
- Perls select emulation on windows
Currently this apparently rules out OS X (which is utterly, dearly,
almost unusably broken), but libev does survive its testsuites there
(with select, the only working backend on OS X), so while not officially
supported (due to lakc of resources) it should generally work there.
> A related (but probably random) question: are there any correctness
> tests for libev?
I use both the libevent regression tests and also have a number of tests
on my own (the latter are all part of the perl module).
> own stuff every night in an automated test harness; I'd be happy to
> add libev (standalone; outside of the other stuff I test) to the mix
> with a variety of platforms and compilers if it would be helpful.
Just run make test in the perl module, and if more is desired, use the
regression test in the libevent+libev tarball.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
