Alexander Ovchinnikov (@Alovchin91) wrote:
> [C]ould you please also upgrade cc to 1.0.69? This version contains fixes to
> find MSVC tools on Windows ARM.
I agree to license my contributions to each file under the terms given at the top of each file I changed.
Co-authored-by: Marc-André Moreau <marcandre.moreau@gmail.com>
Localize the use of the "is git" check to a single place and use more
descriptive variables for the various effects that this check has.
As a nice side effect, the loosly-typed `warnings_are_errors` parameters
that were threaded through functions are now gone.
The deleted `#define`s were dead code correctly identified as such by clang.
```
$ clang-cl --version
clang version 12.0.0
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\apps-x86\Microsoft Visual Studio\2019\BuildTools\VC\Tools\Llvm\bin
```
targets.
There is no case where we have .S files for -msvc targets, so this
filter doesn't filter anything out. IIRC, this is stale code from when
the situation was different in the past.
This reduces the amount of logic that is specific to "-msvc" targets and
makes the work to support clang and clang-cl for Windows, and to support
AAarch64 Windows, easier to review.
Prepare for the removal of the `PartialEq`/`Eq` implementations from
`untrusted`. The goal of such removal is to make timing leaks more
obvious, and to make the absense of timing leaks more clear.
Take a step towards having RSA keys support encryption/decryption
in addition to signing/verification.
No functional changes are intended.
Some documentation was moved around.
The `let _ =` stuff makes it look like we're ignoring the result. It
isn't clear that `with_bad_i` was doing the check we needed. Merge
`with_good_i` and `with_bad_i` into one `with_i` and move the checks to
the calling code.
`big_endian_without_leading_zero_as_input().as_slice_less_safe()` is
equivalent to `big_endian_without_leading_zero()`. Simplify users of the
former to use the latter.
This facilitates moving the unit tests to integration tests.
Simplify the integer parsing code. Instead of jumping through hoops to use
the `untrusted` API for validating the syntax, take advantage of slice
patterns, which weren't available at the time the original code was written.
Eliminate redundancy in checking for non-zero values when parsing positive
integers.
Use normal error handling instead of panicking. That is, don't require/assume that the caller
of `io::Positive::new_non_empty_without_leading_zeros()` already validated the input. This
adds redundant error checking when it is used by `io::der`, but will simplify (future)
callers outside of `io::der`.
Rename the function.
