id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
12359,eventfd_select_interrupter calls fcntl without checking the return code,James E. King III <jim.king@…>,chris_kohlhoff,"This occurs 8 times within the implementation file:

Lines 51 to 55:

{{{
  if (read_descriptor_ != -1)
  {
    ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK);
    ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC);
  }
}}}

Lines 67 to 71:

{{{
    if (read_descriptor_ != -1)
    {
      ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK);
      ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC);
    }
}}}

Lines 78 to 86:

{{{
    if (pipe(pipe_fds) == 0)
    {
      read_descriptor_ = pipe_fds[0];
      ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK);
      ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC);
      write_descriptor_ = pipe_fds[1];
      ::fcntl(write_descriptor_, F_SETFL, O_NONBLOCK);
      ::fcntl(write_descriptor_, F_SETFD, FD_CLOEXEC);
    }
}}}

This goes as far back as 1.54 and is present in the development trunk.  In these cases, what is the correct behavior if fcntl fails?  I assume throwing a boost::system::error_code?  Does any resource need to be released/closed explicitly in these cases?",Bugs,new,To Be Determined,asio,Boost 1.54.0,Problem,,fcntl eventfd asio,