On Wed, Apr 09, 2008 at 06:56:22PM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
> >I have different standards.
>
> No need to get personal with attacks on my "standards".
You said it is a moot point for you, I just pointed out that I have
different standards of what is moot and what isn't.
A
Marc Lehmann wrote:
On Wed, Apr 09, 2008 at 06:15:27PM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
Regardless, if poll() returns zero there's no point in examining revents
anyways right?
The extra test might slow you down when you need it most, when you are in
a tight loop handling I/O ev
On Wed, Apr 09, 2008 at 06:15:27PM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
> Regardless, if poll() returns zero there's no point in examining revents
> anyways right?
The extra test might slow you down when you need it most, when you are in
a tight loop handling I/O events, especially wh
Marc Lehmann wrote:
http://lists.freedesktop.org/archives/dbus/2006-September/005724.html
In case anyone wonders, quoting from gnu/linux manpages is a very bad
idea, they are often very wrong and in contradiciton to both reality and
the unix specification.
The unix specification says:
In e
> >>http://lists.freedesktop.org/archives/dbus/2006-September/005724.html
In case anyone wonders, quoting from gnu/linux manpages is a very bad
idea, they are often very wrong and in contradiciton to both reality and
the unix specification.
The unix specification says:
In each pollfd structur
On Wed, Apr 09, 2008 at 05:34:22PM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
> My reading of that other thread I quoted is basically (a) the standard
> is self-contradictory
I can't really read that from the thread, and the standard is certainly not
self-contradictory, but certainly very h
On Wed, Apr 09, 2008 at 04:40:23PM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
> Here's an interesting thread from another list regarding this exact same
> problem:
>
> http://lists.freedesktop.org/archives/dbus/2006-September/005724.html
>
> I'm still a little hazy on what the "right" answ
Marc Lehmann wrote:
On Wed, Apr 09, 2008 at 04:40:23PM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
Here's an interesting thread from another list regarding this exact same
problem:
http://lists.freedesktop.org/archives/dbus/2006-September/005724.html
I'm still a little hazy on what the "
Brandon Black wrote:
Sorry maybe I wasn't clear. Those error messages I pasted are a
completely separate issue from the realloc thing. I tracked it down now
to the point that I can interpret the messages (and exactly when they
occur) as meaning: when poll_poll() is called, the 0th member of
On Wed, Apr 09, 2008 at 11:17:26PM +0200, Marc Lehmann <[EMAIL PROTECTED]>
wrote:
> (it's actually the unix specification that requires this, btw., not C)
atcually,
C89 4.10.3.4 "If size is zero and ptr is not a null pointer, the
object it points to is freed."^
If a system can't get it ri
Brandon Black wrote:
Sorry maybe I wasn't clear. Those error messages I pasted are a
completely separate issue from the realloc thing. I tracked it down now
to the point that I can interpret the messages (and exactly when they
occur) as meaning: when poll_poll() is called, the 0th member of
> I'm noticing some disparity in how that's actually handled across various
> libcs:
wow, that would be rather horrible, however:
> *OpenBSD: If size is zero and ptr is not a null pointer, the object it
> points to is freed and a new zero size object is returned.
>
> Darwin: If size is zero and
Marc Lehmann wrote:
On Wed, Apr 09, 2008 at 10:49:51AM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
meaningful runtime leakage in practice). The first is that the signals
array isn't ever deallocated. This fixed it for me locally:
thats not a problem, it does not leak (the signals array
On Wed, Apr 9, 2008 at 2:57 PM, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> > Also, the default ev_realloc() does a realloc to zero for allocs of size
> > zero, instead of an actual free(), which results in valgrind reporting a
> > bunch of leaks of size zero at exit. Glibc's docs say realloc() to
On Wed, Apr 09, 2008 at 10:49:51AM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
> meaningful runtime leakage in practice). The first is that the signals
> array isn't ever deallocated. This fixed it for me locally:
thats not a problem, it does not leak (the signals array cannot be
deallocat
I've been running valgrind on some code with an embedded copy of libev.
There are two things in libev that cause pointless valgrind memory
leak warnings (pointless as in they don't constitute any kind of
meaningful runtime leakage in practice). The first is that the signals
array isn't ever
16 matches
Mail list logo
