[mojo-edk] Fix uninitialized reads in EDK dispatchers

mojo/edk/system/data_pipe_consumer_dispatcher.cc

Index: mojo/edk/system/data_pipe_consumer_dispatcher.cc
diff --git a/mojo/edk/system/data_pipe_consumer_dispatcher.cc b/mojo/edk/system/data_pipe_consumer_dispatcher.cc
index 7bf0b0177acdbd0a2a86891d6f6473cbbfab6752..2ed5917dd6166b59241a1cde9e001bf4e660393b 100644
--- a/mojo/edk/system/data_pipe_consumer_dispatcher.cc
+++ b/mojo/edk/system/data_pipe_consumer_dispatcher.cc
@@ -525,9 +525,7 @@ void DataPipeConsumerDispatcher::UpdateSignalsStateNoLock() {
              << " [control_port=" << control_port_.name() << "]";
 
     peer_closed_ = true;
-  }
-
-  if (port_status.has_messages && !in_transit_) {
+  } else if (port_status.has_messages && !in_transit_) {

[Anand Mistry (off Chromium), 2016/05/03 05:51:54]

I think this logic is subtle and unclear. Why not just zero-initialise
port_status?

Also, why is this logic different from the producer dispatcher, given the two
functions are largely the same?

[Ken Rockot(use gerrit already), 2016/05/03 06:16:14]

Sorry, are you asking why they aren't using shared implementation? If so, it's
because they didn't start out looking so similar, and I never took the time to
unify them.

Zero-initializing PortStatus is not the correct thing to do. If GetPortStatus
fails, the PortStatus value should not be used. For example, has_messages is
neither true nor false: it's unspecified.

I don't disagree that the logic is subtle and potentially unclear, but I don't
think I'm making it worse here. Fixing that is beyond the scope of this CL.

[Anand Mistry (off Chromium), 2016/05/03 07:19:10]

I mean that these two functions are mostly the same. But you're changing this to
an "else if" and the producer's condition to just an "else", even though they're
currently both the same "if" condition.
Good point.
I think using the result of the "if" condition in the "else if" branch is
subtle. I would strongly prefer if the condition was more explicit. It's
currently two separate conditionals, which is quite clear when using the result
of the first in the second.

[Ken Rockot(use gerrit already), 2016/05/03 15:19:07]

Oh... oh god. Yikes. I stared at this for like 3 minutes and didn't notice. The
difference was unintentional. Fixed. Thanks!

     ports::ScopedMessage message;
     do {
       int rv = node_controller_->node()->GetMessageIf(control_port_, nullptr,