On 12/02/2012 04:21, Nick Mathewson wrote:
> On Sat, Feb 11, 2012 at 3:15 PM, Ross Lagerwall
> wrote:
>> If we can't trust the compile-time value and we can't detect the runtime
>> behavior then I think the solution I suggested is a reasonable idea.
>
> Agreed.
>
> (Actually, we _could_ detect
On Sat, Feb 11, 2012 at 3:15 PM, Ross Lagerwall wrote:
> If we can't trust the compile-time value and we can't detect the runtime
> behavior then I think the solution I suggested is a reasonable idea.
Agreed.
(Actually, we _could_ detect it at runtime by using fcntl(F_GETFD) on
an fd after we op
On 11/02/2012 18:48, Nick Mathewson wrote:
> On Sat, Feb 11, 2012 at 10:34 AM, Ross Lagerwall
> wrote:
>> In a multi-process/threaded environment, ev_util_read_file()
>> could leak fds to child processes when not using O_CLOEXEC/FD_CLOEXEC.
>
> Hm. I'm not sure I trust "#ifdef O_CLOEXEC" as a te
On Sat, Feb 11, 2012 at 10:34 AM, Ross Lagerwall
wrote:
> In a multi-process/threaded environment, ev_util_read_file()
> could leak fds to child processes when not using O_CLOEXEC/FD_CLOEXEC.
Hm. I'm not sure I trust "#ifdef O_CLOEXEC" as a test for whether
open() supports O_CLOEXEC. Generally,
In a multi-process/threaded environment, ev_util_read_file()
could leak fds to child processes when not using O_CLOEXEC/FD_CLOEXEC.
---
evutil.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/evutil.c b/evutil.c
index 306f037..2bdacaa 100644
--- a/evutil.c
+++ b/evut
