Name Description Size
Algorithm.h A polyfill for `<algorithm>`. 798
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. 6123
AlreadyAddRefed.h Typed temporary pointers for reference-counted smart pointers. 6154
Array.h A compile-time constant-length array with bounds-checking assertions. 2841
ArrayUtils.h Implements various helper functions related to arrays. 5603
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. 1848
Assertions.h Implementations of runtime and static assertion macros for C and C++. 28592
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. 21339
Attributes.h Implementations of various class and method modifier attributes. 43328
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); } 3648
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"). 7599
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. 5069
BufferList.h 21726
Casting.h Cast operations to supplement the built-in casting operations. 7208
ChaosMode.cpp namespace detail 593
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. 2771
Char16.h Implements a UTF-16 character type. 5280
CheckedInt.h Provides checked integers, detecting integer overflow and divide-by-0. 24588
Compiler.h Various compiler checks. 4416
Compression.cpp Our wrappers 2907
Compression.h Various simple compression/decompression functions. 5917
DbgMacro.h a MOZ_DBG macro that outputs a wrapped value to stderr then returns it 6779
DebugOnly.h Provides DebugOnly, a type for variables used only in debug builds (i.e. by assertions). 2893
DefineEnum.h Poor man's reflection for enumerations. 7289
double-conversion 6
DoublyLinkedList.h A doubly-linked list with flexible next/prev naming. 10333
EndianUtils.h Functions for reading and writing integers in various endiannesses. 20900
EnumeratedArray.h EnumeratedArray is like Array, but indexed by a typed enum. 3534
EnumeratedRange.h Iterator over contiguous enum values 6348
EnumSet.h A set abstraction for enumeration values. 6666
EnumTypeTraits.h Type traits for enums. 3009
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|. 16944
FloatingPoint.cpp Implementations of FloatingPoint functions 1438
FloatingPoint.h Various predicates and operations on IEEE-754 floating point types. 21564
FStream.h mozilla_FStream_h 3643
FunctionTypeTraits.h Helpers to manipulate function types that don't fit in TypeTraits.h 4233
GuardObjects.h Implementation of macros to ensure correct use of RAII Auto* objects. 6188
HashFunctions.cpp Implementations of hash functions. 1039
HashFunctions.h Utilities for hashing. 14130
HashTable.h 70611
IntegerPrintfMacros.h Implements the C99 <inttypes.h> interface. 3273
IntegerRange.h Iterator over ranges of integers 5902
IntegerTypeTraits.h Helpers to manipulate integer types that don't fit in TypeTraits.h 3795
JSONWriter.cpp 0 1 2 3 4 5 6 7 8 9 2483
JSONWriter.h A JSON pretty-printer class. 13326
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. 19214
LinuxSignal.h 1277
lz4.c -************************************ Tuning parameters ************************************ 96277
lz4.h --- Dependency --- 35083
MacroArgs.h Implements various macros meant to ease the use of variadic macros. 3389
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. 15183
Maybe.h A class for optional values and in-place lazy construction. 18129
MaybeOneOf.h A class storing one of two optional value types that supports in-place lazy construction. 4436
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
Move.h C++11-style, but C++98-usable, "move references" implementation. 9089
moz.build 4074
NonDereferenceable.h A pointer wrapper indicating that the pointer should not be dereferenced. 4662
NotNull.h 8694
NullPtr.h Implements a mozilla::IsNullPointer<T> type trait. 940
Opaque.h An opaque integral type supporting only comparison operators. 1146
OperatorNewExtensions.h A version of |operator new| that eschews mandatory null-checks. 2228
Pair.h A class holding a pair of objects that tries to conserve storage space. 5932
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. 4971
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. 5370
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. 3446
RandomNum.cpp Note - Bug 1500115 has been opened to discuss simplifying or improving this function in the future; however, the function is secure as-is right now. Further improvements may be made to reduce complexity, improve robustness, or take advantage of OS-specific API improvements as they become available. 4170
RandomNum.h Routines for generating random numbers 1109
Range.h mozilla_Range_h 2330
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). 2234
RangedPtr.h Implements a smart pointer asserted to remain within a range specified at construction. 7555
RecordReplay.cpp 9157
RecordReplay.h Public API for Web Replay. 21129
ReentrancyGuard.h Small helper class for asserting uses of a class are non-reentrant. 1350
RefCounted.h CRTP refcounting templates. Do not use unless you are an Expert. 9398
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 15909
Result.h A type suitable for returning either a value or an error from a function. 15546
ResultExtensions.h Extensions to the Result type to enable simpler handling of XPCOM/NSPR results. 1572
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.) 5456
RollingMean.h Calculate the rolling mean of a series of values. 2635
Saturate.h Provides saturation arithmetics for scalar types. 6153
Scoped.h DEPRECATED: Use UniquePtr.h instead. 8757
ScopeExit.h RAII class for executing arbitrary actions at scope end. 3467
SegmentedVector.h 10730
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. 12875
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. 7184
Span.h constexpr 31902
SplayTree.h A sorted tree with optimal access times, where recently-accessed elements are faster to access again. 7668
Sprintf.h Provides a safer sprintf for printing to fixed-size character arrays. 1110
SPSCQueue.h Single producer single consumer lock-free and wait-free queue. 14705
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 1833
STYLE 628
TaggedAnonymousMemory.cpp 3202
TaggedAnonymousMemory.h 2985
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. 3800
tests 60
TextUtils.h Character/text operations. 5381
ThreadLocal.h Cross-platform lightweight thread local data wrappers. 6471
ThreadSafeWeakPtr.h A thread-safe weak pointer 11391
ToString.h Utilities for converting an object to a string representation. 857
Tuple.h A variadic tuple class. 17479
TypedEnumBits.h MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS allows using a typed enum as bit flags. 5869
Types.h mfbt foundational types and macros. 4559
TypeTraits.h Template-based metaprogramming and type-testing facilities. 38386
UniquePtr.h Smart pointer managing sole ownership of a resource. 23482
UniquePtrExtensions.h Useful extensions to UniquePtr. 1565
Unused.cpp 438
Unused.h unused 1106
Utf8.cpp 1123
Utf8.h UTF-8-related functionality, including a type-safe structure representing a UTF-8 code unit. 19968
Variant.h A template class for tagged unions. 28063
Vector.h A type/length-parametrized vector class. 45585
WeakPtr.h Weak pointer functionality, implemented as a mixin for use with any class. 9345
WindowsVersion.h 5994
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/autoconf/sanitize.m4), that in appropriately configured builds verify at runtime that integral arithmetic doesn't overflow. 11586
XorShift128PlusRNG.h The xorshift128+ pseudo-random number generator. 4402