We out-of-line the relevant functions because assertions can generate
quite a bit of code, and we'd rather let the compiler determine if these
functions should be inlined now.
NonDereferenceable denotes the intent that a pointer will (most likely) not be
dereferenced, but its numeric value may be used for e.g. logging purposes.
Dereferencing operations are explicitly disabled to avoid unintentional misuses.
Casting is still possible between related types (same as with raw pointers),
but pointers stay safely stored inside NonDereferenceable objects. These casts
do not trigger `clang++ -fsanitize=vptr` errors.
MozReview-Commit-ID: 5885pB7hSFR
--HG--
extra : rebase_source : 3c4011da64d84f1b19991742b76bafbffa90d590
There are three things we want to be true:
a) If the child sends a large value and the parent can't allocate enough space
for it we use an infallible allocation so the parent dies with an OOM.
b) If a fuzzer generates (huge-length, small-data) we don't try to allocate
huge-length bytes; knowing that the read will fail.
c) No fuzzer-specific branches in the core IPC serialization code.
Finally, this makes (huge-length, small-data) consistent with other cases where
the data is potentially truncated: ReadParam returns false.
MozReview-Commit-ID: 6nDKrw5z4pt
--HG--
extra : rebase_source : 58372d29139e9545a6ed2852c7243affeab6fdb7
Otherwise, one can do thinkos like:
MakeScopeExit(...);
and the scope exiting function will execute much earlier than the
intended:
auto guard = MakeScopeExit(...);
This is a `constexpr` alternative to HashString(const char16_t*). We can't make
HashString(const char16_t*) itself `constexpr` because HashUntilZero(const T*)
isn't in a form that older compilers (like GCC 4.9) allow to be made
`constexpr`. (The trick to satisfying those compilers is to use recursion
instead of iteration, to get the function into a single `return` statement.)
This requires making a bunch of other functions `constexpr` as well. It also
requires adding MOZ_{PUSH,POP}_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING
macros to avoid some MSVC weirdness.
The introduction of RotateLeft5() partly undoes one of the patches from bug
1443342, but that's unavoidable.
This change will help with static allocation of static atoms (bug 1411469).
MozReview-Commit-ID: 7r3PnrQXb29
VS 2017 15.6 (March 2018) doesn't seem to understand
`*DeclVal<SharedFontList*>()` anymore.
To work around this issue, the pointed-to type is now extracted in a separate
struct, for which we provide a specialization for raw pointers, so we don't
encounter the shaky `*DeclVal<T*>()` statement anymore.
MozReview-Commit-ID: FuslManbfdB
--HG--
extra : rebase_source : be3813aa9a028e6891cb3de1fc4faae5bde0348e
mozWritePoison secretly depended on the passed-in pointer being aligned
as though it were a pointer to uintptr_t, as it used bare stores to
C-casted pointers to accomplish poisoning. But this is an unnecessary
limitation: we can use memcpy and rely on the compiler to appropriately
inline the store to an unaligned store instruction if necessary.
The documentation for mozWritePoison says that only an even number of
sizeof(uintptr_t) bytes are overwritten; any trailing bytes are not
touched. This documentation doesn't correspond to how the function
actually works. The function as written will happily overwrite trailing
bytes and any bytes not contained in the object, if the passed-in size
isn't divisible by sizeof(uintptr_t). Let's fix that.
Nathan Froyd
Ryan VanderMeulen
Aaron Klotz
Gerald Squelart
Masatoshi Kimura
Jon Coppeard
Jeff Walden
Alex Gaynor
Margareta Eliza Balazs
Nicholas Nethercote
Tom Bannister
Sebastian Hengst
Tristan Bourvon
Sylvestre Ledru
Jonathan Kew
Henri Sivonen
Bogdan Tara
Emilio Cobos Álvarez
Narcis Beleuzu
Dorel Luca
Jason Orendorff