Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#5668 closed Bugs (wontfix)

epoll_reactor implicit type conversion warnings:

Reported by: David Benoit <benoit@…> Owned by: chris_kohlhoff
Milestone: To Be Determined Component: asio
Version: Boost 1.47.0 Severity: Problem
Keywords: Cc:

Description

I'm using boost 1.46.1 with gcc 4.1.2-44-rhel5 and -Wconversion and I get the following warnings (which are a problem as soon as I turn on -Werror):

boost/asio/detail/impl/epoll_reactor.ipp: In constructor 'boost::asio::detail::epoll_reactor::epoll_reactor(boost::asio::io_service&)': boost/asio/detail/impl/epoll_reactor.ipp:53: warning: negative integer implicitly converted to unsigned type boost/asio/detail/impl/epoll_reactor.ipp: In member function 'int boost::asio::detail::epoll_reactor::register_descriptor(boost::asio::detail::socket_type, boost::asio::detail::epoll_reactor::descriptor_state*&)': boost/asio/detail/impl/epoll_reactor.ipp:109: warning: negative integer implicitly converted to unsigned type boost/asio/detail/impl/epoll_reactor.ipp: In member function 'void boost::asio::detail::epoll_reactor::start_op(int, boost::asio::detail::socket_type, boost::asio::detail::epoll_reactor::descriptor_state*&, boost::asio::detail::reactor_op*, bool)': boost/asio/detail/impl/epoll_reactor.ipp:154: warning: negative integer implicitly converted to unsigned type boost/asio/detail/impl/epoll_reactor.ipp: In member function 'void boost::asio::detail::epoll_reactor::interrupt()': boost/asio/detail/impl/epoll_reactor.ipp:319: warning: negative integer implicitly converted to unsigned type

In all of these cases, the line in question is of the form:

ev.events = EPOLLIN | EPOLLERR | EPOLLET;

Specifically, that EPOLLET (1 << 31), which is unsigned as an int, is included. (For example, line 61 doesn't have the same warning).

Could the values here (EPOLLET at a minimum) please be wrapped as uint32_t (the type of ev.events)? (i.e. replacing all instances of EPOLLET with uint32_t(EPOLLET) removes the warning).

Thanks!

Change History (6)

comment:1 by anonymous, 11 years ago

Version: Boost 1.46.1Boost 1.47.0

I have checked, and this is still a problem in boost 1.47.0. Is there any plan to address this?

comment:2 by David Benoit <benoit@…>, 11 years ago

Anyone?

comment:3 by chris_kohlhoff, 10 years ago

Resolution: wontfix
Status: newclosed

I am not going to make this change. Asio's use is the approach shown in epoll's man page. Furthermore, -Wconversion is not part of -Wall or -Wextra and it is not feasible (or desirable) to suppress all possible warnings.

If you want to propose that these constants be made unsigned then I suggest you raise a ticket against glibc.

in reply to:  3 comment:4 by anonymous, 10 years ago

Replying to chris_kohlhoff:

I am not going to make this change. Asio's use is the approach shown in epoll's man page. Furthermore, -Wconversion is not part of -Wall or -Wextra and it is not feasible (or desirable) to suppress all possible warnings.

I don't think OP implied that -Wconversion was a part of -Wall or -Wextra, merely that specification of -Werror turns all warnings into errors, and thus this warning is an error. Although I agree with you that it is not possible to suppress all warnings, all reasonably expected warnings should be accounted for, but -Wconversion is a legitimate option. In this case the use of the #define-d value of EPOLLET produces a value that is a different sign than the rvalue of the statement. The fact that "events" member of struct epoll_event is defined as uint32_t suggests that a wrapper such as suggested would be appropriate in assigning the value.

If you want to propose that these constants be made unsigned then I suggest you raise a ticket against glibc.

Until and unless glibc starts defining these as variables with real types, this isn't going to happen. The responsibility thus lies with the library/application developer to use it appropriately.

In this case, it is true that the man page for epoll suggests the use as you have it, but man pages are not definitive sources of all usage, merely examples.

I find it unfortunate that you are unwilling to accept this as a bug.

comment:5 by chris_kohlhoff, 10 years ago

I have no idea what you mean about "real types", since integer constants can be unsigned. The glibc maintainers evidently agree and a fix was applied late last year to make the constant unsigned:

http://sourceware.org/bugzilla/show_bug.cgi?id=13538

comment:6 by benoit@…, 10 years ago

Thanks Chris! I'll see if the tools guys are more willing to get up to date on glibc than they are on removing -Wconversion.

Note: See TracTickets for help on using tickets.