This prevents a potential race and simplifies the code a bit by keeping the
bytes read separate instead of using mData, which is modified from another
thread from OnDataAvailable.
Relaxed atomics are fine for these, since they don't guard any memory.
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
When using AF_CONN addresses, don't put these in the COOKIE
chunk. For these addresses it is possible to reconstruct them
locally. Conceptually, addresses are something to be shared
with the peer, but in the case of AF_CONN this might not be
the case. Therefore, zero then out.
Thanks to Natalie Silvanovich of Google Project Zero for
finding and reporting the issue.
To respond dynamically to the pref change, the mAppVersion string needs
to be rebuilt.
Includes some minor improvements for corner cases and removes leftover
b2g junk.
When setting up connectivity, e.g. with new network detection, the pref
wouldn't be checked (or honored), resulting in spurious startup calls
despite being preffed off. This fixes that.
Resolves#1474
LIST and RETR still appear to work as intended on ftp:// URLs after my changes. I wasn't able to test STOR because the browser doesn't appear to support FTP uploads at this time (although our FTP implementation appears perfectly capable of doing an FTP upload.)
If I understood the issue correctly, though, what we're doing is ensuring that we receive a preliminary 100 response from the FTP server for a given action before jumping to the 200 code describing what we do if the action was completed. Even though it makes no logical sense for a server to say an action was completed before it was initiated, someone could write a really annoying FTP server that takes advantage of this fact to crash the browser if they wanted.
