Cleaning up compiler warnings for nICEr. Major highlights:
- set _WINSOCK_DEPRECATED_NO_WARNINGS define in nicer.gyp for Windows
builds of nICEr to avoid warnings about inet_addr use in ice_ctx.c:102,
ice_ctx.c:297, ice_parser.c:465, and transport_addr_reg.c:143.
- move nr_ice_accumulate_count from ice_ctx.{h|c} to stun_util.{h|c}
as nr_accumulate_count to quiet warnings in turn_client_ctx.c and
stun_client_ctx.c.
- stun_msg.{h|c} - change nr_stun_attr_data_.length,
nr_stun_message_attribute.encoding_length and nr_stun_message_.length
from int to UINT2 (not size_t since other lengths in this header are
UINT2).
- stun_codec.{h|c} - lengths and offsets changed from int to UINT2 to
match changes in stun_msg.{h|c}
- r_data.{h|c} - change Data.len from int to size_t
- nr_crypto.{h|c} - change nr_ice_crypto_vtbl_ lengths from int to size_t
MozReview-Commit-ID: EF5v79RpqbI
--HG--
extra : rebase_source : ead30e2359ea6a6aada4dd222137302ba86fb972
Because the nr_transport_addr_check_compatibility check also includes
protocol, it was failing checks that used to pass. However, the actual
address used was created farther down in code by copying the current
address and setting the protocol to TCP. Moving that address copy up
in the processing flow lets the more stringent check work.
MozReview-Commit-ID: 95SOQzxuxXB
--HG--
extra : rebase_source : 95f4cf6d9f10ee4f81c56d7bbe8027c46749cfb8
Adding trickle field that will allow us to flag trickled candidates
on about:webrtc.
Also added label field to NrIceCandidate to facilitate showing the
raw candidate info on about:webrtc.
MozReview-Commit-ID: HuP3IxYOOBJ
--HG--
extra : rebase_source : 975cb5b29b2aef233f856bfbdc8c325535d24272
Two variables, contains_mac_based_ipv6 and contains_teredo_ipv6, were
added that are set but never used. This will cause compiler warnings
issues in the future.
MozReview-Commit-ID: C5ZReH94RpM
--HG--
extra : rebase_source : 50e06da3c093a118151d840b7d25a979afce6321
I missed doing this in the original patch because my mozconfig defined the
CFLAGS globally to include -fsanitize-coverage.
MozReview-Commit-ID: 4QdiIgdfAm2
--HG--
extra : rebase_source : bfd1ef5097b91c23913c0349a04154f18f60eef5
Counting the code points in a UTF-8 string is simple enough that that it is
not worthwhile to use the locale-dependent parts of the C standard library
for the task.
MozReview-Commit-ID: 6Tzd5NHub3B
--HG--
extra : rebase_source : d452896317d354ee85c817533cba3116adf5277e
In the case of e10s, the ctx flags for default route only (and less
importantly in this case, proxy only) were not set on the ice ctx
when SetStunAddrs was called in PeerConnectionMedia.
MozReview-Commit-ID: CldUpJfaaH3
--HG--
extra : rebase_source : 6223722275d4741519890d4d2b8436b05ca43155
When I added this check during the modifications for Bug 1345511 (Move
nICEr stun local address discovery to an IPC call to enable future
sandbox restrictions on content process) I originally thought this was
more of an error condition, but it really isn't. It can happen each
time the following method(s) is called:
PeerConnectionMedia::EnsureTransports() ->
GatherIfReady() ->
EnsureIceGathering_s()
MozReview-Commit-ID: Ct3teqXBxWd
--HG--
extra : rebase_source : a116a8423fd999c4746e9375b8f42a6d908a1ea7
Building these as part of the webkit lib adds unnecessary dependencies on Mozilla code for things that only case about the webrtc static lib.
MozReview-Commit-ID: 7ThU7hAwRX0
--HG--
extra : rebase_source : eef256711e205d023a647e6196dcc61e657f6e28
Expose a tweaked version of nr_ice_get_local_addresses to allow callers to
provide pre-fetched stun addrs if they are available. By default, the normal
call to nr_ice_gather calls this with no pre-fetched stun addrs (read
non-e10s). In e10s, the stun addrs are discovered on the main process and
provided to nr_ice_get_local_addreses. When nr_ice_gather is called from
the content process the local addresses have already been gathered.
In the past, nr_ice_get_local_addresses also applied policy (by removing
duplicate addrs, and, based on stun prefs, removing loopback and/or
link_local addrs. This functionality has been moved to
nr_ice_set_local_addresses where other policy is being applied (like
default route only, forcing specific interfaces, and prioritization).
Because we're now serializing nr_local_addr (wrapped by NrIceStunAddr), we
can't assume that certain pointer references in the source nr_local_addr
are correct when calling nr_local_addr_copy. New non-pointer-arithmetic
version of setting up the pointer on the copied nr_local_addr is used. Also
easier to understand when walking up to it the first time.
MozReview-Commit-ID: KVRFl4dfr7J
--HG--
extra : rebase_source : c0437700ad77ee3b7f98947d3505551ca9ed43e9
