Attempting to build a standalone libFuzzer in Fuchsia's default toolchain for the purpose of cross-compiling the unit tests revealed a number of not-quite-proper type conversions. Fuchsia's toolchain include -std=c++17 and -Werror, among others, leading to many errors like -Wshorten-64-to-32, -Wimplicit-float-conversion, etc.
Most of these have been addressed by simply making the conversion explicit with a static_cast. These typically fell into one of two categories: 1) conversions between types where high precision isn't critical, e.g. the "energy" calculations for InputInfo, and 2) conversions where the values will never reach the bits being truncated, e.g. DftTimeInSeconds is not going to exceed 136 years.
The major exception to this is the number of features: there are several places that treat features as size_t, and others as uint32_t. This change makes the decision to cap the features at 32 bits. The maximum value of a feature as produced by TracePC::CollectFeatures is roughly:
(NumPCsInPCTables + ValueBitMap::kMapSizeInBits + ExtraCountersBegin() - ExtraCountersEnd() + log2(SIZE_MAX)) * 8
It's conceivable for extremely large targets and/or extra counters that this limit could be reached. This shouldn't break fuzzing, but it will cause certain features to collide and lower the fuzzers overall precision. To address this, this change adds a warning to TracePC::PrintModuleInfo about excessive feature size if it is detected, and recommends refactoring the fuzzer into several smaller ones.
Do we really need long doubles here (and throughout this function)? Can we just use log?