Couple of bugs

Marc Lehmann schmorp at schmorp.de
Wed Feb 25 22:19:05 CET 2009


On Wed, Feb 25, 2009 at 10:37:36AM -0500, Steve Grubb <sgrubb at redhat.com> wrote:
> On Wednesday 25 February 2009 01:46:36 am Marc Lehmann wrote:
> > On Mon, Feb 23, 2009 at 09:22:28AM -0500, Steve Grubb <sgrubb at redhat.com> 
> wrote:
> 
> > Warnings are also often more or less bogus (for example, the aliasing
> > warnings in some versions of gcc).
> 
> Those warnings are telling you that the code would run faster if they were 

That's total bullshit.

> fixed. But that's not really the warnings I see. I checked using this:
> 
> -W -Wall -Wshadow -Wformat -Wfloat-equal -Wundef

These options cause bogus warnings with valid C code. If you enable them,
you have to deal with them.

> > Just FYI: I do not get a warning about that with my compiler (which is
> > gcc-4.3.2).
> 
> Are you compiling with -Wundef? 

No, why should I?

> > There is lots of code in libev that will never execute under spoecific
> > circumstances (for example, all asserts).
> 
> So, what happens if I define NDEBUG to get rid of the asserts?

Nothing, the code still will not execute.

> Isn't it bad to make function calls inside asserts since they get
> deleted?

No, it is not.

It is fine to enable warnings for your code, especially if you are
inexperienced enough to think that function calls in asserts are bad.

I would encourage you to do that.

But please don't try to enforce this on other people's code.

> assert (("libev: active index mismatch in heap", ev_active (ANHE_w (heap [i])) 
> == i));

And there are no function calls in this line.

> Hmm....if you run "strings" on the resulting program and grep for "ev", you 
> will see that each of these are stored as text in the program and the assert 
> is not executed:
> 
> Was that intentional?

Yes, the intent of all those asserts is to never trigger, if you mean
that. Some do trigger if the user code is buggy, though.

The compiler can sometimes know that, but I usually do not have an assert
for that (sometimes I do).

> Hint? Its dead code.

Call it documentation then - the algorithms used for epoll change often, and
in the past, it was beneficial to have these in the code.

It has no egative effect.

> If nev == 0, it returns. That's it. Checking for nev == 0 again is
> wasting clock cycles, but it could also be an indication that some
> code that updated nev got deleted in the past. I can't tell what the
> intentions were, so I'm asking.

The intention is to make it sure. Besides, I doubt that this check is
wasting any cycles (at runtime) - do you have evidence for that?

> >Please do read the valgrind section in the manual.
> 
> My project's requirements are clean valgrind run no matter who's code its in.

That's easy, valgrind has lots of features that allow you to get a clean
run with libev. Those features exist because valgrind often reports things
that are not memleaks, or problems, so you can exclude these form the report.

Again, the valgrind section in the manual explains this a bit.

> >Your patch is architecture dependend and will not work when 
> >destructors are not working (which is not uncommon).
> 
> So, which version of gcc are they working reliably in?

gcc is irrelevant. libev is written in ISO C with extensions, not in gcc.

> I did not see any arch 
> specific warnings or hints in the gcc docs. We've been using destructors in 
> security sensitive libraries since gcc 3.4 on at least 6 different arches.

And I have been using gcc for 15 years no, including being a member of the
gcc steering committee. Maybe I am too old and too "experienced" and it is
a non-issue, but I still get mail form a lot of people who use a much muhc
older gcc for example.

libev strives to be portable, which is not the same thing as "gcc since
gcc 3.4".

> I did some more looking around. In ev.c is a function, pipecb. What if a
> SIGCHLD is delivered when the read is called?

Either the read is executed again in the next iteration or not, depending
on whether it was successful or not.

> Same issue in evpipe_write for the writes.

Either you haven't mentioned an issue yet, or you have issues with
apparently working code. If you think you found a bug, it would be nice if
yxou explained what you think the bug is.

On Wed, Feb 25, 2009 at 11:52:54AM -0500, Steve Grubb <sgrubb at redhat.com> wrote:
> My bad...these do get executed. But I am tempted to define NDEBUG, though, to 
> remove the extraneous text. So, I guess the comment about function calls in 
> the assert expressions would be an issue.

You are free to define NDEBUG if you want (this is documented, btw.).

There are no known issues with function calls in asserts so far...

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list