Name Description Size
Algorithm.h A polyfill for `<algorithm>`. 4319
Alignment.h Functionality related to memory alignment. 3685
AllocPolicy.h An allocation policy concept, usable for structures and algorithms to control how memory is allocated and how failures are handled. 6125
AlreadyAddRefed.h Typed temporary pointers for reference-counted smart pointers. 6501
Array.h A compile-time constant-length array with bounds-checking assertions. 3144
ArrayUtils.h Implements various helper functions related to arrays. 5708
Assertions.cpp The crash reason is defined as a global variable here rather than in the crash reporter itself to make it available to all code, even libraries like JS that don't link with the crash reporter directly. This value will only be consumed if the crash reporter is used by the target application. 2009
Assertions.h Implementations of runtime and static assertion macros for C and C++. 28209
AtomicBitfields.h 21844
Atomics.h Implements (almost always) lock-free atomic operations. The operations here are a subset of that which can be found in C++11's <atomic> header, with a different API to enforce consistent memory ordering constraints. Anyone caught using |volatile| for inter-thread memory safety needs to be sent a copy of this header and the C++11 standard. 19554
Attributes.h Implementations of various class and method modifier attributes. 49053
BinarySearch.h The BinarySearch() algorithm searches the given container |aContainer| over the sorted index range [aBegin, aEnd) for an index |i| where |aContainer[i] == aTarget|. If such an index |i| is found, BinarySearch returns |true| and the index is returned via the outparam |aMatchOrInsertionPoint|. If no index is found, BinarySearch returns |false| and the outparam returns the first index in [aBegin, aEnd] where |aTarget| can be inserted to maintain sorted order. Example: Vector<int> sortedInts = ... size_t match; if (BinarySearch(sortedInts, 0, sortedInts.length(), 13, &match)) { printf("found 13 at %lu\n", match); } The BinarySearchIf() version behaves similarly, but takes |aComparator|, a functor to compare the values with, instead of a value to find. That functor should take one argument - the value to compare - and return an |int| with the comparison result: * 0, if the argument is equal to, * less than 0, if the argument is greater than, * greater than 0, if the argument is less than the value. Example: struct Comparator { int operator()(int aVal) const { if (mTarget < aVal) { return -1; } if (mTarget > aVal) { return 1; } return 0; } explicit Comparator(int aTarget) : mTarget(aTarget) {} const int mTarget; }; Vector<int> sortedInts = ... size_t match; if (BinarySearchIf(sortedInts, 0, sortedInts.length(), Comparator(13), &match)) { printf("found 13 at %lu\n", match); } 7372
BitSet.h An object like std::bitset but which provides access to the underlying storage. The limited API is due to expedience only; feel free to flesh out any std::bitset-like members. 4440
BloomFilter.h A counting Bloom filter implementation. This allows consumers to do fast probabilistic "is item X in set Y?" testing which will never answer "no" when the correct answer is "yes" (but might incorrectly answer "yes" when the correct answer is "no"). 10667
Buffer.h A move-only type that wraps a mozilla::UniquePtr<T[]> and the length of the T[]. Unlike mozilla::Array, the length is a run-time property. Unlike mozilla::Vector and nsTArray, does not have capacity and assocatiated growth functionality. Unlike mozilla::Span, mozilla::Buffer owns the allocation it points to. 5889
BufferList.h 20093
Casting.h Cast operations to supplement the built-in casting operations. 11622
ChaosMode.cpp namespace detail 551
ChaosMode.h When "chaos mode" is activated, code that makes implicitly nondeterministic choices is encouraged to make random and extreme choices, to test more code paths and uncover bugs. 2705
Char16.h Implements a UTF-16 character type. 5061
CheckedInt.h Provides checked integers, detecting integer overflow and divide-by-0. 27055
CompactPair.h A class holding a pair of objects that tries to conserve storage space. 8839
Compiler.h Various compiler checks. 1244
DbgMacro.h a MOZ_DBG macro that outputs a wrapped value to stderr then returns it 6764
DebugOnly.h Provides DebugOnly, a type for variables used only in debug builds (i.e. by assertions). 3220
DefineEnum.h Poor man's reflection for enumerations. 10933
double-conversion
DoublyLinkedList.h A doubly-linked list with flexible next/prev naming. 16511
EndianUtils.h Functions for reading and writing integers in various endiannesses. 19300
EnumeratedArray.h EnumeratedArray is like Array, but indexed by a typed enum. 3230
EnumeratedRange.h Iterator over contiguous enum values 7367
EnumSet.h A set abstraction for enumeration values. 7919
EnumTypeTraits.h Type traits for enums. 4749
fallible.h Explicit fallible allocation Memory allocation (normally) defaults to abort in case of failed allocation. That is, it never returns NULL, and crashes instead. Code can explicitely request for fallible memory allocation thanks to the declarations below. The typical use of the mozilla::fallible const is with placement new, like the following: foo = new (mozilla::fallible) Foo(); The following forms, or derivatives, are also possible but deprecated: foo = new ((mozilla::fallible_t())) Foo(); const mozilla::fallible_t f = mozilla::fallible_t(); bar = new (f) Bar(); It is also possible to declare method overloads with fallible allocation alternatives, like so: class Foo { public: void Method(void *); void Method(void *, const mozilla::fallible_t&); }; Foo foo; foo.Method(nullptr, mozilla::fallible); If that last method call is in a method that itself takes a const fallible_t& argument, it is recommended to propagate that argument instead of using mozilla::fallible: void Func(Foo &foo, const mozilla::fallible_t& aFallible) { foo.Method(nullptr, aFallible); } 1734
FastBernoulliTrial.h class FastBernoulliTrial: Efficient sampling with uniform probability When gathering statistics about a program's behavior, we may be observing events that occur very frequently (e.g., function calls or memory allocations) and we may be gathering information that is somewhat expensive to produce (e.g., call stacks). Sampling all the events could have a significant impact on the program's performance. Why not just sample every N'th event? This technique is called "systematic sampling"; it's simple and efficient, and it's fine if we imagine a patternless stream of events. But what if we're sampling allocations, and the program happens to have a loop where each iteration does exactly N allocations? You would end up sampling the same allocation every time through the loop; the entire rest of the loop becomes invisible to your measurements! More generally, if each iteration does M allocations, and M and N have any common divisor at all, most allocation sites will never be sampled. If they're both even, say, the odd-numbered allocations disappear from your results. Ideally, we'd like each event to have some probability P of being sampled, independent of its neighbors and of its position in the sequence. This is called "Bernoulli sampling", and it doesn't suffer from any of the problems mentioned above. One disadvantage of Bernoulli sampling is that you can't be sure exactly how many samples you'll get: technically, it's possible that you might sample none of them, or all of them. But if the number of events N is large, these aren't likely outcomes; you can generally expect somewhere around P * N events to be sampled. The other disadvantage of Bernoulli sampling is that you have to generate a random number for every event, which can be slow. [significant pause] BUT NOT WITH THIS CLASS! FastBernoulliTrial lets you do true Bernoulli sampling, while generating a fresh random number only when we do decide to sample an event, not on every trial. When it decides not to sample, a call to |FastBernoulliTrial::trial| is nothing but decrementing a counter and comparing it to zero. So the lower your sampling probability is, the less overhead FastBernoulliTrial imposes. Probabilities of 0 and 1 are handled efficiently. (In neither case need we ever generate a random number at all.) The essential API: - FastBernoulliTrial(double P) Construct an instance that selects events with probability P. - FastBernoulliTrial::trial() Return true with probability P. Call this each time an event occurs, to decide whether to sample it or not. - FastBernoulliTrial::trial(size_t n) Equivalent to calling trial() |n| times, and returning true if any of those calls do. However, like trial, this runs in fast constant time. What is this good for? In some applications, some events are "bigger" than others. For example, large allocations are more significant than small allocations. Perhaps we'd like to imagine that we're drawing allocations from a stream of bytes, and performing a separate Bernoulli trial on every byte from the stream. We can accomplish this by calling |t.trial(S)| for the number of bytes S, and sampling the event if that returns true. Of course, this style of sampling needs to be paired with analysis and presentation that makes the size of the event apparent, lest trials with large values for |n| appear to be indistinguishable from those with small values for |n|. 16995
FloatingPoint.cpp Implementations of FloatingPoint functions 1443
FloatingPoint.h Various predicates and operations on IEEE-754 floating point types. 22113
FStream.h mozilla_FStream_h 3643
FunctionRef.h A generic callable type that can be initialized from any compatible callable, suitable for use as a function argument for the duration of the function call (and no longer). 8983
FunctionTypeTraits.h for size_t 4194
Fuzzing.h Additional definitions and implementation for fuzzing code 3802
HashFunctions.cpp Implementations of hash functions. 1025
HashFunctions.h Utilities for hashing. 14593
HashTable.h 73500
HelperMacros.h MOZ_STRINGIFY Macros 658
InitializedOnce.h aValue 9203
IntegerRange.h Iterator over ranges of integers 6841
IntegerTypeTraits.h StdintTypeForSizeAndSignedness returns the stdint integer type of given size (can be 1, 2, 4 or 8) and given signedness (false means unsigned, true means signed). 2116
JSONWriter.cpp 0 1 2 3 4 5 6 7 8 9 2483
JSONWriter.h A JSON pretty-printer class. 19882
JsRust.h Checking for jsrust crate availability for linking. For testing, define MOZ_PRETEND_NO_JSRUST to pretend that we don't have jsrust. 611
Latin1.h Latin-1 operations (i.e. a byte is the corresponding code point). (Note: this is *not* the same as the encoding of windows-1252 or latin1 content on the web. In Web terms, this encoding corresponds to "isomorphic decode" / "isomorphic encoding" from the Infra Standard.) 9028
Likely.h MOZ_LIKELY and MOZ_UNLIKELY macros to hint to the compiler how a boolean predicate should be branch-predicted. 765
LinkedList.h A type-safe doubly-linked list class. 22609
Literals.h Helpers for units on integer literals. 1092
MacroArgs.h Implements various macros meant to ease the use of variadic macros. 3739
MacroForEach.h Implements a higher-order macro for iteratively calling another macro with fixed leading arguments, plus a trailing element picked from a second list of arguments. 10689
MathAlgorithms.h mfbt maths algorithms. 14739
Maybe.h A class for optional values and in-place lazy construction. 34772
MaybeOneOf.h A class storing one of two optional value types that supports in-place lazy construction. 4898
MaybeStorageBase.h Internal storage class used e.g. by Maybe and Result. This file doesn't contain any public declarations. 2921
MemoryChecking.h Provides a common interface to the ASan (AddressSanitizer) and Valgrind functions used to mark memory in certain ways. In detail, the following three macros are provided: MOZ_MAKE_MEM_NOACCESS - Mark memory as unsafe to access (e.g. freed) MOZ_MAKE_MEM_UNDEFINED - Mark memory as accessible, with content undefined MOZ_MAKE_MEM_DEFINED - Mark memory as accessible, with content defined With Valgrind in use, these directly map to the three respective Valgrind macros. With ASan in use, the NOACCESS macro maps to poisoning the memory, while the UNDEFINED/DEFINED macros unpoison memory. With no memory checker available, all macros expand to the empty statement. 4202
MemoryReporting.h Memory reporting infrastructure. 826
MoveOnlyFunction.h IsOwning 1865
moz.build 4757
MPSCQueue.h Multiple Producer Single Consumer lock-free queue. Allocation-free is guaranteed outside of the constructor. This is a direct C++ port from https://docs.rs/signal-hook/0.3.17/src/signal_hook/low_level/channel.rs.html#1-235 with the exception we are using atomic uint64t to have 15 slots in the ring buffer (Rust implem is 5 slots, we want a bit more). 14817
MruCache.h 4892
NeverDestroyed.h 2473
NonDereferenceable.h A pointer wrapper indicating that the pointer should not be dereferenced. 4630
NotNull.h 15878
Opaque.h An opaque integral type supporting only comparison operators. 1137
OperatorNewExtensions.h A version of |operator new| that eschews mandatory null-checks. 2228
PairHash.h Utilities for hashing pairs. 2089
Path.h Represents the native path format on the platform. 773
PodOperations.h Operations for zeroing POD types, arrays, and so on. These operations are preferable to memset, memcmp, and the like because they don't require remembering to multiply by sizeof(T), array lengths, and so on everywhere. 5205
Poison.cpp A poison value that can be used to fill a memory space with an address that leads to a safe crash when dereferenced. 6407
Poison.h A poison value that can be used to fill a memory space with an address that leads to a safe crash when dereferenced. 3266
RandomNum.cpp 4019
RandomNum.h Routines for generating random numbers 1635
Range.h mozilla_Range_h 2688
RangedArray.h A compile-time constant-length array, with bounds-checking assertions -- but unlike mozilla::Array, with indexes biased by a constant. Thus where mozilla::Array<int, 3> is a three-element array indexed by [0, 3), mozilla::RangedArray<int, 8, 3> is a three-element array indexed by [8, 11). 2327
RangedPtr.h Implements a smart pointer asserted to remain within a range specified at construction. 8771
ReentrancyGuard.h Small helper class for asserting uses of a class are non-reentrant. 1179
RefCounted.cpp 1446
RefCounted.h CRTP refcounting templates. Do not use unless you are an Expert. 12052
RefCountType.h MozRefCountType is Mozilla's reference count type. We use the same type to represent the refcount of RefCounted objects as well, in order to be able to use the leak detection facilities that are implemented by XPCOM. Note that this type is not in the mozilla namespace so that it is usable for both C and C++ code. 1187
RefPtr.h 18209
Result.h A type suitable for returning either a value or an error from a function. 30774
ResultExtensions.h Extensions to the Result type to enable simpler handling of XPCOM/NSPR results. 14242
ResultVariant.h A type suitable for returning either a value or an error from a function. 2331
ReverseIterator.h An iterator that acts like another iterator, but iterating in the negative direction. (Note that not all iterators can iterate in the negative direction.) 6066
RollingMean.h Calculate the rolling mean of a series of values. 2393
Saturate.h Provides saturation arithmetics for scalar types. 6158
ScopeExit.h RAII class for executing arbitrary actions at scope end. 3331
SegmentedVector.h 11254
SHA1.cpp Explanation of H array and index values: The context's H array is actually the concatenation of two arrays defined by SHA1, the H array of state variables (5 elements), and the W array of intermediate values, of which there are 16 elements. The W array starts at H[5], that is W[0] is H[5]. Although these values are defined as 32-bit values, we use 64-bit variables to hold them because the AMD64 stores 64 bit values in memory MUCH faster than it stores any smaller values. Rather than passing the context structure to shaCompress, we pass this combined array of H and W values. We do not pass the address of the first element of this array, but rather pass the address of an element in the middle of the array, element X. Presently X[0] is H[11]. So we pass the address of H[11] as the address of array X to shaCompress. Then shaCompress accesses the members of the array using positive AND negative indexes. Pictorially: (each element is 8 bytes) H | H0 H1 H2 H3 H4 W0 W1 W2 W3 W4 W5 W6 W7 W8 W9 Wa Wb Wc Wd We Wf | X |-11-10 -9 -8 -7 -6 -5 -4 -3 -2 -1 X0 X1 X2 X3 X4 X5 X6 X7 X8 X9 | The byte offset from X[0] to any member of H and W is always representable in a signed 8-bit value, which will be encoded as a single byte offset in the X86-64 instruction set. If we didn't pass the address of H[11], and instead passed the address of H[0], the offsets to elements H[16] and above would be greater than 127, not representable in a signed 8-bit value, and the x86-64 instruction set would encode every such offset as a 32-bit signed number in each instruction that accessed element H[16] or higher. This results in much bigger and slower code. 12910
SHA1.h Simple class for computing SHA1. 1683
SharedLibrary.h Path charset agnostic wrappers for prlink.h. 1205
SmallPointerArray.h A vector of pointers space-optimized for a small number of elements. 7564
Span.h 35222
SplayTree.h A sorted tree with optimal access times, where recently-accessed elements are faster to access again. 7668
SPSCQueue.h Single producer single consumer lock-free and wait-free queue. 15214
StaticAnalysisFunctions.h Functions that are used as markers in Gecko code for static analysis. Their purpose is to have different AST nodes generated during compile time and to match them based on different checkers implemented in build/clang-plugin 1867
StringBuffer.h This structure precedes the string buffers "we" allocate. It may be the case that nsTAString::mData does not point to one of these special buffers. The mDataFlags member variable distinguishes the buffer type. When this header is in use, it enables reference counting, and capacity tracking. NOTE: A string buffer can be modified only if its reference count is 1. 11992
STYLE 629
TaggedAnonymousMemory.cpp 3038
TaggedAnonymousMemory.h 3006
Tainting.h Creates a Tainted<> wrapper to enforce data validation before use. 12773
TemplateLib.h Reusable template meta-functions on types and compile-time values. Meta- functions are placed inside the 'tl' namespace to avoid conflict with non- meta functions of the same name (e.g., mozilla::tl::FloorLog2 vs. mozilla::FloorLog2). When constexpr support becomes universal, we should probably use that instead of some of these templates, for simplicity. 3362
tests
TextUtils.h Character/text operations. 9191
ThreadLocal.h Cross-platform lightweight thread local data wrappers. 6996
ThreadSafety.h 6431
ThreadSafeWeakPtr.h A thread-safe weak pointer 10849
ToString.h Utilities for converting an object to a string representation. 857
Try.h MOZ_TRY(expr) is the C++ equivalent of Rust's `try!(expr);`. First, it evaluates expr, which must produce a Result value. On success, it discards the result altogether. On error, it immediately returns an error Result from the enclosing function. 1758
TsanOptions.h Default options for ThreadSanitizer. 4197
TypedEnumBits.h MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS allows using a typed enum as bit flags. 5874
Types.h mfbt foundational types and macros. 4443
UniquePtr.h Smart pointer managing sole ownership of a resource. 24407
UniquePtrExtensions.cpp 1410
UniquePtrExtensions.h Useful extensions to UniquePtr. 10162
Unused.cpp 438
Unused.h unused 1106
Utf8.cpp 1179
Utf8.h UTF-8-related functionality, including a type-safe structure representing a UTF-8 code unit. 25263
Variant.h A template class for tagged unions. 33403
Vector.h A type/length-parametrized vector class. 50262
WasiAtomic.h 5591
WeakPtr.h Weak pointer functionality, implemented as a mixin for use with any class. 12387
WindowsVersion.h mozilla_WindowsVersion_h 2313
WrappingOperations.h Math operations that implement wraparound semantics on overflow or underflow. While in some cases (but not all of them!) plain old C++ operators and casts will behave just like these functions, there are three reasons you should use these functions: 1) These functions make *explicit* the desire for and dependence upon wraparound semantics, just as Rust's i32::wrapping_add and similar functions explicitly produce wraparound in Rust. 2) They implement this functionality *safely*, without invoking signed integer overflow that has undefined behavior in C++. 3) They play nice with compiler-based integer-overflow sanitizers (see build/moz.configure/toolchain.configure), that in appropriately configured builds verify at runtime that integral arithmetic doesn't overflow. 10407
XorShift128PlusRNG.h The xorshift128+ pseudo-random number generator. 4402