Name Description Size
gtest 2854
TestAlgorithm.cpp 2361
TestArray.cpp 958
TestArrayUtils.cpp 11541
TestAtomicBitfields.cpp 8108
TestAtomics.cpp 9016
TestBinarySearch.cpp 5673
TestBitSet.cpp 3809
TestBloomFilter.cpp 4337
TestBufferList.cpp 13146
TestCasting.cpp 12181
TestCeilingFloor.cpp 2428
TestCheckedInt.cpp Addition / subtraction checks 18948
TestCompactPair.cpp 6321
TestCountPopulation.cpp 1253
TestCountZeroes.cpp 4832
TestDefineEnum.cpp 3024
TestDoublyLinkedList.cpp 7423
TestEndian.cpp 20636
TestEnumeratedArray.cpp 1619
TestEnumSet.cpp 9370
TestEnumTypeTraits.cpp Feature check for EnumTypeFitsWithin. 5696
TestFastBernoulliTrial.cpp FastBernoulliTrial takes care to avoid screwing up on edge cases. The checks here all look pretty dumb, but they exercise paths in the code that could exhibit undefined behavior if coded naïvely. 5436
TestFloatingPoint.cpp 28390
TestFunctionRef.cpp 3726
TestFunctionTypeTraits.cpp 7982
TestHashTable.cpp 3380
TestIntegerRange.cpp 5455
TestJSONWriter.cpp 15036
TestLinkedList.cpp 9709
TestMacroArgs.cpp 1930
TestMacroForEach.cpp 1883
TestMathAlgorithms.cpp 4355
TestMaybe.cpp 50429
TestNonDereferenceable.cpp 5572
TestNotNull.cpp 13024
TestPoisonArea.cpp Code in this file needs to be kept in sync with code in nsPresArena.cpp. We want to use a fixed address for frame poisoning so that it is readily identifiable in crash dumps. Whether such an address is available without any special setup depends on the system configuration. All current 64-bit CPUs (with the possible exception of PowerPC64) reserve the vast majority of the virtual address space for future hardware extensions; valid addresses must be below some break point between 2**48 and 2**54, depending on exactly which chip you have. Some chips (notably amd64) also allow the use of the *highest* 2**48 -- 2**54 addresses. Thus, if user space pointers are 64 bits wide, we can just use an address outside this range, and no more is required. To accommodate the chips that allow very high addresses to be valid, the value chosen is close to 2**63 (that is, in the middle of the space). In most cases, a purely 32-bit operating system must reserve some fraction of the address space for its own use. Contemporary 32-bit OSes tend to take the high gigabyte or so (0xC000_0000 on up). If we can prove that high addresses are reserved to the kernel, we can use an address in that region. Unfortunately, not all 32-bit OSes do this; OSX 10.4 might not, and it is unclear what mobile OSes are like (some 32-bit CPUs make it very easy for the kernel to exist in its own private address space). Furthermore, when a 32-bit user space process is running on a 64-bit kernel, the operating system has no need to reserve any of the space that the process can see, and generally does not do so. This is the scenario of greatest concern, since it covers all contemporary OSX iterations (10.5+) as well as Windows Vista and 7 on newer amd64 hardware. Linux on amd64 is generally run as a pure 64-bit environment, but its 32-bit compatibility mode also has this property. Thus, when user space pointers are 32 bits wide, we need to validate our chosen address, and possibly *make* it a good poison address by allocating a page around it and marking it inaccessible. The algorithm for this is: 1. Attempt to make the page surrounding the poison address a reserved, inaccessible memory region using OS primitives. On Windows, this is done with VirtualAlloc(MEM_RESERVE); on Unix, mmap(PROT_NONE). 2. If mmap/VirtualAlloc failed, there are two possible reasons: either the region is reserved to the kernel and no further action is required, or there is already usable memory in this area and we have to pick a different address. The tricky part is knowing which case we have, without attempting to access the region. On Windows, we rely on GetSystemInfo()'s reported upper and lower bounds of the application memory area. On Unix, there is nothing devoted to the purpose, but seeing if madvise() fails is close enough (it *might* disrupt someone else's use of the memory region, but not by as much as anything else available). Be aware of these gotchas: 1. We cannot use mmap() with MAP_FIXED. MAP_FIXED is defined to _replace_ any existing mapping in the region, if necessary to satisfy the request. Obviously, as we are blindly attempting to acquire a page at a constant address, we must not do this, lest we overwrite someone else's allocation. 2. For the same reason, we cannot blindly use mprotect() if mmap() fails. 3. madvise() may fail when applied to a 'magic' memory region provided as a kernel/user interface. Fortunately, the only such case I know about is the "vsyscall" area (not to be confused with the "vdso" area) for *64*-bit processes on Linux - and we don't even run this code for 64-bit processes. 4. VirtualQuery() does not produce any useful information if applied to kernel memory - in fact, it doesn't write its output at all. Thus, it is not used here. 17657
TestRandomNum.cpp We're going to check that random number generation is sane on a basic level - That is, we want to check that the function returns success and doesn't just keep returning the same number. Note that there are many more tests that could be done, but to really test a PRNG we'd probably need to generate a large set of randoms and perform statistical analysis on them. Maybe that's worth doing eventually? For now we should be fine just performing a dumb test of generating 5 numbers and making sure they're all unique. In theory, it is possible for this test to report a false negative, but with 5 numbers the probability is less than one-in-a-trillion. 1987
TestRange.cpp 967
TestRefPtr.cpp 2919
TestResult.cpp 20660
TestRollingMean.cpp 2531
TestSaturate.cpp 4302
TestScopeExit.cpp 1298
TestSegmentedVector.cpp 10954
TestSHA1.cpp 14084
TestSIMD.cpp 28115
TestSmallPointerArray.cpp 6716
TestSplayTree.cpp 9569
TestSPSCQueue.cpp Generate a monotonically increasing sequence of numbers. 6406
TestTextUtils.cpp 50342
TestThreadSafeWeakPtr.cpp 3928
TestTypedEnum.cpp Per Clang documentation, "Note that marketing version numbers should not be used to check for language features, as different vendors use different numbering schemes. Instead, use the feature checking macros." 18992
TestUniquePtr.cpp 12712
TestUtf8.cpp 26562
TestVariant.cpp 47614
TestVector.cpp 22666
TestWeakPtr.cpp 4348
TestWrappingOperations.cpp 25913
TestXorShift128PlusRNG.cpp 3034