a lot of re-import warnings have cropped up. While I appreciate
their studiousness on this, the problem is that removing some
of these exports in the API crate could mean that future users
who want access to some API features that aren't used in this
configuration are now unaccessible.
I think it's not a huge problem at the moment, just spam-cleaning
the warnings because there are too many to deal with carefully
at the moment.
we need to tag out a release, so we're temporarily forking
`smoltcp` at its current head, testing it, and holding it
there until a full release is tagged out that captures all
of the good stuff that has been going on in that repo since
June.
unwrap on a routine always returns None, so the unwrap() has no meaning
(probably originally introduced just as a way to get match arms to
have the same return result without thinking too much about it).
panics happen due to certain default states of the EC
wire protocol, due to a MAC address being passed in that is
not unicast when garbage data is present.
this needs to stabilize once they tag out a release but for now
it cleans up the warnings.
will have to remember to do a cargo updae on that repository though
from time to time to get the latest code...
Mark `MemoryRange::as_slice()` and `MemoryRange::as_slice_mut()` as
unsafe.
This is due to the fact that not all representable types can be cast to
an arbitrary value. For example, if Process A sends random values to
Process B, then Process B casts the memory to a slice of `bool`, then
any values that are not 0 or 1 are undefined.
Because these functions can leak UB into the program, they are marked as
unsafe.
This patch adds `unsafe {}` blocks to all instances where this function
is called. Additionally, all instances have been checked to verify that
they do not cast to any invalid types -- most use `u8` or `u32`.
Additionally, the long-deprecated `MemoryRange::from_parts()` call was
removed, since that causes UB without being marked as unsafe.
Signed-off-by: Sean Cross <sean@xobs.io>
ssid scans can now be in-progress, and they also record
the time elapsed since the last scan was performed.
this allows the network manager to be a bit smarter about when
it decides to kick off a scan.
the ssid scan dialog box is also updated to show
the scan results in progress. This addresses #336.
