Split the field arithmetic implementations into `FieldElement`,
`FieldElement32`, and `FieldElement64`. `FieldElement` is a type alias for one
of `FieldElement32` or `FieldElement64`, depending on feature selection.
`field.rs` contains tests and code which is generic with respect to the
implementation (e.g., inversions), while `field_32bit.rs` and `field_64bit.rs`
contain the implementation-specific code.
The implementation is not completely hidden, since `FieldElement32` and
`FieldElement64` are tuple structs whose elements are public; `pub(crate)`
doesn't seem to work for tuple structs.
Similarly, the constants file is split over multiple files, depending on the
implementation.
libcollections was recently merged into liballoc:
https://github.com/rust-lang/rust/pull/42648
I went ahead and also added an "alloc" feature which no_std users can use to opt
into liballoc features (i.e. any code using Vec). This should have no effect on
anything but no_std usage. It does make it possible for people without
allocators to use curve25519-dalek if they want though. Might be nice for
"bare metal" development.
All that said, from what I can gather liballoc, while not "stable", should
likely stick around for the forseeable future.
Some backstory on the liballoc/libcollections merge here:
https://github.com/rust-lang/rust/pull/42565
- Gate no_std on the "std" feature
- Import core when std is present
- Import collections when std is absent
- Add a placeholder gated "use" directive for Box in curve.rs
Use ::core in lieu of ::std, allowing this crate to be usable in #![no_std]
environments.
Gates features that presently depend on ::std (presently just rand) behind a
"std" cargo feature, which is enabled by default.
This adds a dependency on the `rand` crate, used to construct an
OS-backed CSPRNG. The implementation in this commit is somewhat
inefficient as it constructs a new OsRng object every time; it might be
better to construct it once. (Seems like a lot of overhead for a few
getrandom(2) calls...)
