Boost C++ Libraries: Ticket #8348: asio::detail::epoll_reactor::descriptor_state c'tor doesn't initialize all POD members https://svn.boost.org/trac10/ticket/8348 <pre class="wiki">epoll_reactor::descriptor_state::descriptor_state() : operation(&amp;epoll_reactor::descriptor_state::do_complete) { 5. uninit_member: Non-static class member "next_" is not initialized in this constructor nor in any functions that it calls. 7. uninit_member: Non-static class member "prev_" is not initialized in this constructor nor in any functions that it calls. 9. uninit_member: Non-static class member "reactor_" is not initialized in this constructor nor in any functions that it calls. 11. uninit_member: Non-static class member "descriptor_" is not initialized in this constructor nor in any functions that it calls. 13. uninit_member: Non-static class member "registered_events_" is not initialized in this constructor nor in any functions that it calls. CID 10922 (#2 of 2): Uninitialized pointer field (UNINIT_CTOR)15. uninit_member: Non-static class member "shutdown_" is not initialized in this constructor nor in any functions that it calls. } </pre> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/8348 Trac 1.4.3 chris_kohlhoff Fri, 24 May 2013 03:44:07 GMT severity changed https://svn.boost.org/trac10/ticket/8348#comment:1 https://svn.boost.org/trac10/ticket/8348#comment:1 <ul> <li><strong>severity</strong> <span class="trac-field-old">Problem</span> → <span class="trac-field-new">Cosmetic</span> </li> </ul> <p> These descriptor_state objects are recycled via an object_pool. The next_ and prev_ members are set by the pool. The other members are set after the object has been obtained from the pool. It would seem that all code paths do set the members correctly and so the warning is purely a cosmetic issue. I'll look at fixing in the future provided there are no performance impacts. </p> Ticket Richard <legalize@…> Fri, 24 May 2013 12:20:52 GMT <link>https://svn.boost.org/trac10/ticket/8348#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/8348#comment:2</guid> <description> <p> ok. It seems a little odd that we rely on the code that constructs these objects to properly initialize them, as that is usually the responsibility of the constructor of the object. </p> <p> I have another question. </p> <p> In epoll_reactor.ipp: </p> <pre class="wiki">int epoll_reactor::register_descriptor(socket_type descriptor, epoll_reactor::per_descriptor_data&amp; descriptor_data) { descriptor_data = allocate_descriptor_state(); { mutex::scoped_lock descriptor_lock(descriptor_data-&gt;mutex_); descriptor_data-&gt;reactor_ = this; descriptor_data-&gt;descriptor_ = descriptor; descriptor_data-&gt;shutdown_ = false; } epoll_event ev = { 0, { 0 } }; ev.events = EPOLLIN | EPOLLERR | EPOLLHUP | EPOLLPRI | EPOLLET; descriptor_data-&gt;registered_events_ = ev.events; ev.data.ptr = descriptor_data; int result = epoll_ctl(epoll_fd_, EPOLL_CTL_ADD, descriptor, &amp;ev); if (result != 0) return errno; return 0; } </pre><p> Why are all the other members set inside the scope of the lock, but registered_events_ is modified outside the scope of the lock? </p> </description> <category>Ticket</category> </item> </channel> </rss>