On Mon, Nov 04, 2013 at 09:07:25PM -0500, Benjamin Kaduk <ka...@mit.edu> wrote:
> A simple grep would not be enough, one would need to find the part
Well:
# grep fd_rearm_all *
ev.c:fd_rearm_all (EV_P)
Binary file ev.o matches
ev_epoll.c: fd_rearm_all (EV_A);
ev_kqueue.c: fd_rearm_all (EV_A);
ev_port.c: fd_rearm_all (EV_A);
That would instantly tell you that the function is likely in use, and
removing it shouldn't be done lightly.
> where the different backend codes are included via the preprocessor
> instead of being compiled as separate objects.
Well, it was enough for me to find that it is indeed used elsewhere.
> drew my attention to it). Yes, it would cause a symbol to escape the
> object's linkage, that's your tradeoff to analyze.
It would also needlessly increase object size, and possibly inhibit
optimisation. For no gain.
> your decision is already made; please don't take the above as an
> effort to sway your decision, it's just an explanation of my
> mindset/thought process.)
Likewise here :)
> Well, this is with the clang 3.2 rev 170710 included in the FreeBSD
> base system from a svn snapshot from some time ago, compiling the
> embedded libev 4.04 from the krb5 tree. Advances in either libev or
> clang could have rendered this datapoint useless.
Indeed, libev is at 4.15 nowadays, so that probably applies. Thanks for
pointing it out!
> I will say once more that I do think that the parenthesis around the
> bitwise operators (trimmed from the context) is very helpful for
> readers of the code, and ask for its inclusion. The rest of these
> patches are not really useful for anything other than removing
> warnings, and ignoring them is fine by me.
I am not sure they are helpful for readers. I, for one, get regularly
tripped at such extra parentheses, because I always wonder why I put them
there (something fishy going on?).
I don't doubt that you found it useful, and that you are not alone, but
I don't think the sweeping generalisation over readers in general is
warranted.
In any case, it wouldn't have been a problem if clang didn't have this
warning. GCC for example, has much more thoughtfully implemented warnings
(for example, it knows about the assert((,)) idiom, which isn't uncommon).
So it seems the main problem is the bad choice of compiler - not yours,
necessarily, but it illustrates the point I made about chasing compiler
warnings, as all compilers have different 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
