If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/electronicarts/EASTL shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 6mo ago
• 26+ active contributors
• Distributed ownership (top contributor 41% of recent commits)
• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 6mo ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live electronicarts/EASTL repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/electronicarts/EASTL.

What it runs against: a local clone of electronicarts/EASTL — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in electronicarts/EASTL | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 205 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of electronicarts/EASTL. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/electronicarts/EASTL.git
#   cd EASTL
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of electronicarts/EASTL and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "electronicarts/EASTL(\\.git)?\\b" \\
  && ok "origin remote is electronicarts/EASTL" \\
  || miss "origin remote is not electronicarts/EASTL (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "include/EASTL/allocator.h" \\
  && ok "include/EASTL/allocator.h" \\
  || miss "missing critical file: include/EASTL/allocator.h"
test -f "include/EASTL/algorithm.h" \\
  && ok "include/EASTL/algorithm.h" \\
  || miss "missing critical file: include/EASTL/algorithm.h"
test -f "include/EASTL/hash_map.h" \\
  && ok "include/EASTL/hash_map.h" \\
  || miss "missing critical file: include/EASTL/hash_map.h"
test -f "include/EASTL/vector.h" \\
  && ok "include/EASTL/vector.h" \\
  || miss "missing critical file: include/EASTL/vector.h"
test -f "include/EASTL/internal" \\
  && ok "include/EASTL/internal" \\
  || miss "missing critical file: include/EASTL/internal"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 205 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~175d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/electronicarts/EASTL"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

EASTL (Electronic Arts Standard Template Library) is a high-performance C++ template library providing containers (vector, list, map, deque, bitset), algorithms, and iterators optimized for game development and real-time systems. It replaces std:: with EA:: implementations tuned for minimal overhead, predictable memory behavior, and platform-specific optimizations across embedded to server architectures. Header-only template library: include/eastl/ contains all container definitions (vector.h, list.h, map.h, deque.h, bitset.h, etc.). benchmark/source/ contains performance regression tests for each container type. doc/ holds design rationale and best practices. CMakeLists.txt enables optional standalone builds; intended for integration as include path in downstream projects.

Game engine developers, embedded systems engineers, and performance-critical application builders at EA and other studios who need STL-compatible containers with deterministic performance, custom allocators, and zero-overhead abstractions rather than std::library trade-offs.

Production-ready and actively maintained. The codebase is 5.6M lines of C++, has extensive benchmark suite (benchmark/source/*.cpp), CI pipeline (.github/workflows/c-cpp.yml), and comprehensive documentation (doc/). Current maintenance passed through multiple senior engineers; commit recency and issue triage visible in GitHub workflows indicate ongoing active stewardship.

Low risk for stable consumption. Monolithic codebase means single repository risk, but no external dependency ties (self-contained STL replacement). Main risk: API surface is massive (50+ container/algorithm types); breaking changes between major versions require careful upgrade planning. Recommend pinning to minor version. Single or dual maintainers visible from CREDITS, so key-person dependency exists.

Actively maintained with regular benchmark additions and performance tuning. Recent work visible in benchmark/source/ (BenchmarkTupleVector.cpp, BenchmarkHash.cpp suggest hash container and tuple_vector bonus feature development). Documentation in doc/Bonus/tuple_vector_readme.md indicates newer data structure adoption. CI pipeline (c-cpp.yml) runs on push, indicating continuous integration maturity.

git clone https://github.com/electronicarts/EASTL.git
cd EASTL
mkdir build && cd build
cmake ..
make
# Run benchmarks
./benchmark/BenchmarkVector

Daily commands: EASTL is header-only; include in your project via CMake (add_subdirectory or link to include/) or copy include/eastl/ into your project. For benchmarks: cmake .. && make && ./benchmark/BenchmarkVector (uses CMake, no external package manager required; Conan/vcpkg metadata present but optional).

• include/EASTL/allocator.h — Core allocator abstraction that underpins memory management across all EASTL containers; every custom allocator implementation depends on this interface.
• include/EASTL/algorithm.h — Defines all standard algorithms (sort, find, transform, etc.); heavily used by containers and user code, making it a load-bearing utility layer.
• include/EASTL/hash_map.h — Hash-based associative container; demonstrates EASTL's approach to collision handling and iteration efficiency—foundational for understanding the library's design philosophy.
• include/EASTL/vector.h — Most commonly used dynamic array container; entry point for many users and demonstrates core container patterns used throughout EASTL.
• include/EASTL/internal — Internal implementation details and platform-specific atomic/arch operations; required reading to understand how EASTL achieves cross-platform high performance.
• CMakeLists.txt — Build configuration and project structure; essential for integrating EASTL into other projects and understanding supported platforms.
• doc/Design.md — Documents design rationale, performance trade-offs, and divergences from STL; critical for understanding why EASTL makes certain choices.

Add a New Container Type

1. Create header in include/EASTL/ following existing container naming (e.g., new_container.h). Define the container class inheriting appropriate base behavior and aliasing default allocator type. (include/EASTL/new_container.h)
2. Implement required iterator types (const_iterator, reverse_iterator, etc.) using EASTL's iterator traits from algorithm.h and ensure operator== and operator< for sorting support. (include/EASTL/new_container.h)
3. Add allocator-aware constructor and ensure swap() method exists; follow patterns in vector.h for exception safety and allocator propagation (C++17 construct_at pattern). (include/EASTL/new_container.h)
4. If fixed-size variant needed, create include/EASTL/fixed_new_container.h using fixed_allocator.h pattern; validate max capacity at compile-time with static_assert. (include/EASTL/fixed_new_container.h)
5. Add benchmarks in benchmark/source/BenchmarkNewContainer.cpp measuring insertion, iteration, and memory usage against std:: or similar; integrate into EASTLBenchmark.cpp. (benchmark/source/BenchmarkNewContainer.cpp)

Add a New Algorithm Function

1. Open include/EASTL/algorithm.h and add function template declaration with typename Iterator, Predicate, and Value parameters; document preconditions (e.g., sorted range, valid dereferencing). (include/EASTL/algorithm.h)
2. Implement the algorithm inline or in a detail namespace; prefer iterator-pair API (first, last) over container API for maximal generality; use call_traits from bonus/call_traits.h for parameter passing. (include/EASTL/algorithm.h)
3. Add benchmark function in benchmark/source/BenchmarkAlgorithm.cpp comparing against std::algorithm variant; measure on typical container sizes (1K, 100K elements). (benchmark/source/BenchmarkAlgorithm.cpp)
4. Document in doc/Modules.md or relevant section; note complexity guarantees (O(n), O(n log n)) and when algorithm is cache-friendly vs. STL equivalent. (doc/Modules.md)

Add Platform-Specific Atomic Operation

1. Create new arch-specific file in include/EASTL/internal/atomic/arch/ named arch_my_operation.h (e.g., arch_cas_fetch.h). (include/EASTL/internal/atomic/arch/arch_my_operation.h)
2. Implement inline asm or compiler builtin for operation (e.g., __sync_val_compare_and_swap for GCC/Clang, MSVC intrinsics for MSVC); wrap in preprocessor guards for target architecture (x86, ARM, etc.). (include/EASTL/internal/atomic/arch/arch_my_operation.h)
3. Update include/EASTL/internal/atomic/arch/arch.h to conditionally include your new header based on detected compiler/CPU; add fallback for unsupported platforms. (include/EASTL/internal/atomic/arch/arch.h)
4. Add test cases calling atomic operation via include/EASTL/atomic.h public API to verify correctness across platforms before merging. (include/EASTL/atomic.h)

Add a Bonus Utility Data Structure

1. Create new header in include/EASTL/bonus/ (e.g., my_structure.h) for specialized, non-standard containers optimized for specific use cases (cache, streaming, intrusive lists). (include/EASTL/bonus/my_structure.h)
2. Implement using EASTL allocator abstraction; document trade-offs vs. standard container (e.g., 'better cache locality for sequential access, worse for random'). (include/EASTL/bonus/my_structure.h)
3. Add comprehensive example and rationale in doc/Bonus/my_structure_readme.md explaining when to use this vs. standard container. (doc/Bonus/my_structure_readme.md)

1. EASTL_ALLOCATOR_TYPE macro must be defined before including headers if using custom allocators; default may not suit your memory strategy. 2) Iterator invalidation semantics differ subtly from STL in some containers (e.g., list, deque); review doc/Gotchas.md. 3) Intrusive vs non-intrusive containers have different node ownership; choose wrong variant and memory leaks ensue. 4) String implementation (EASTL::string) uses fixed-buffer optimization; large strings may not behave like std::string. 5) No C++98 support; requires C++11 minimum. 6) eastl_size_t and eastl_ssize_t are platform-specific; avoid mixing with size_t on mixed architectures.

• Allocator strategy pattern — EASTL's entire design revolves around pluggable allocators (EASTL_ALLOCATOR_TYPE); understanding custom allocators is essential for memory budgeting in game engines and embedded systems
• Intrusive containers — EASTL offers intrusive_list, intrusive_set where node structure is embedded in user data; critical for cache-coherent and zero-allocation data structures in performance-sensitive code
• Small String Optimization (SSO) — EASTL::string uses fixed-buffer storage for small strings avoiding heap allocation; understanding SSO thresholds avoids unexpected performance cliffs when string size exceeds buffer
• Iterator invalidation semantics — Different EASTL containers invalidate iterators differently than STL equivalents (e.g., vector reallocation, list splice); documented in Gotchas.md and critical for correctness
• Deque block-based storage — EASTL deque uses fixed-size blocks to enable O(1) front/back operations; understanding block layout explains memory fragmentation and iterator invalidation patterns
• Hash table collision resolution — EASTL::hash_map/hash_set use configurable hash functions and probe strategies; BenchmarkHash.cpp shows performance sensitivity to collision handling on large tables
• Tuple vector (data structure) — EASTL bonus feature (doc/Bonus/tuple_vector_readme.md) optimizes memory layout for SoA (Structure of Arrays) patterns; critical for SIMD vectorization in game physics and rendering

• facebook/folly — Alternative high-performance C++ containers library with similar allocator customization and cache-conscious data structures
• abseil/abseil-cpp — Google's C++ stdlib extensions providing containers and algorithms optimized for large-scale systems; direct competitor for performance-critical codebases
• boost/container — Boost library offering std-compatible containers with custom allocator support; predecessor influence on EASTL design
• electronicarts/EABase — Companion EA repository providing core primitives (platform macros, assertions, type traits) that EASTL depends on for cross-platform builds
• electronicarts/EAStdC — EA's C standard library bindings and extensions; often used alongside EASTL for complete runtime environment

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for bonus/ container utilities

The bonus/ directory contains specialized containers (fixed_ring_buffer, fixed_tuple_vector, intrusive_sdlist, intrusive_slist, compressed_pair, flags) but there's no visible test/ directory in the file structure. These bonus containers are non-standard and need robust test coverage to prevent regressions. This is high-value because users rely on these for performance-critical code.

• [ ] Create test/bonus/ directory structure mirroring include/EASTL/bonus/
• [ ] Add unit tests for fixed_ring_buffer.h covering edge cases (full buffer, empty buffer, wraparound)
• [ ] Add unit tests for fixed_tuple_vector.h with various tuple types and sizes
• [ ] Add unit tests for intrusive_sdlist.h and intrusive_slist.h with insertion/deletion scenarios
• [ ] Add unit tests for compressed_pair.h verifying empty base optimization
• [ ] Integrate tests into CMakeLists.txt and c-cpp.yml GitHub Actions workflow

Add benchmark coverage for bonus/ containers and expand algorithm benchmarks

The benchmark/ directory has benchmarks for core containers (vector, deque, list, map, set) but is missing benchmarks for bonus containers and many algorithms in algorithm.h. Performance is EASTL's core value proposition, so demonstrating superior performance across all components is critical.

• [ ] Create benchmark/source/BenchmarkBonusContainers.cpp covering fixed_ring_buffer, fixed_tuple_vector, and intrusive lists
• [ ] Create benchmark/source/BenchmarkAlgorithmAdvanced.cpp for algorithms like find_if, transform, copy variants that aren't in existing benchmarks
• [ ] Add performance comparison against std::vector/std::list equivalents where applicable
• [ ] Update benchmark/CMakeLists.txt to include new benchmark files
• [ ] Add new benchmark results to doc/Benchmarks.md with charts/tables

Expand doc/Modules.md with specific API reference links and design rationale for each header

doc/Modules.md exists but likely lacks detailed explanations of when/why to use specific containers. Looking at the rich set of headers (allocator_malloc, atomic, bitvector, any, array), new contributors and users need clear guidance on which component solves which problem. This reduces onboarding friction and increases library adoption.

• [ ] Analyze include/EASTL/*.h headers and create a comprehensive matrix in doc/Modules.md mapping each header to: use cases, performance characteristics, and alternatives
• [ ] Add specific examples to doc/Modules.md for non-obvious choices (e.g., when to use bitvector vs bitset, when to use fixed_ring_buffer vs deque)
• [ ] Document the atomic.h and atomic_raw.h differentiation and lock-free guarantees
• [ ] Add a section on allocator.h and allocator_malloc.h strategy and when custom allocators are beneficial
• [ ] Link each module section to relevant benchmark results in doc/Benchmarks.md

• Add comprehensive unit tests for include/eastl/bitset.h (BitSet is present in benchmarks but no dedicated test coverage visible in repo structure); create tests/bitset_test.cpp following pattern of existing container tests
• Expand doc/FAQ.md with real-world examples comparing EASTL vs std:: performance for vector reallocation, string SSO behavior, and map vs unordered_map trade-offs specific to game loops (3-5 concrete code examples)
• Add benchmark for include/eastl/tuple.h and doc/Bonus/tuple_vector_readme.md features; BenchmarkTupleVector.cpp exists but lacks documentation in Benchmarks.md on when to use tuple_vector over vector<struct>

EASTL is a well-maintained C++ template library with a strong security posture overall. No critical vulnerabilities were identified from the static analysis of the file structure and documentation. The identified low-severity concerns are common considerations for C++ container libraries and relate to proper usage patterns rather than inherent flaws. The library appears to follow good practices with clear documentation (BestPractices.md, Gotchas.md), proper licensing, and active maintenance. Primary recommendations focus on defensive programming practices: comprehensive bounds checking in all container operations, safe integer arithmetic in size calculations, proper memory management in custom allocators, and compile-time validation of template parameters. Users should ensure they follow EASTL's documented best practices when integrating this library into their applications.

• Low · Potential Integer Overflow in Container Operations — include/EASTL/fixed_allocator.h, include/EASTL/fixed_hash_map.h, include/EASTL/fixed_hash_set.h, include/EASTL/fixed_list.h, include/EASTL/fixed_map.h, include/EASTL/fixed_set.h. EASTL is a template library that implements various containers (vector, deque, hash_map, etc.). Container operations involving size calculations could potentially be vulnerable to integer overflow if not properly validated, especially in fixed_allocator and fixed_* containers where capacity is predetermined. Fix: Review all size calculation operations in container implementations to ensure proper bounds checking and overflow prevention. Use safe integer arithmetic libraries or add explicit overflow checks before allocations.
• Low · Missing Input Validation in String Operations — include/EASTL/string.h, include/EASTL/algorithm.h. EASTL includes string handling functionality. Without reviewing the actual source code, potential vulnerabilities could exist in string operations (substring, find, replace) if buffer bounds are not properly validated, potentially leading to buffer overflows. Fix: Implement comprehensive bounds checking in all string manipulation functions. Add assertions and runtime checks to prevent out-of-bounds access.
• Low · Unsafe Memory Operations in Allocator — include/EASTL/allocator.h, include/EASTL/allocator_malloc.h, include/EASTL/core_allocator.h. Custom allocators (allocator.h, allocator_malloc.h, core_allocator.h) may have potential issues if they don't properly handle edge cases like null pointer dereferences, use-after-free, or double-free scenarios. Fix: Implement comprehensive memory safety checks including null pointer validation, use-after-free detection, and proper cleanup in destructors. Consider using RAII patterns consistently.
• Low · Potential Information Disclosure via Intrusive Containers — include/EASTL/bonus/intrusive_sdlist.h, include/EASTL/bonus/intrusive_slist.h. Intrusive containers (intrusive_sdlist.h, intrusive_slist.h) maintain pointers to external data structures. Improper handling could expose memory layout information or enable arbitrary memory access if not properly constrained. Fix: Ensure intrusive containers have strong ownership semantics and access controls. Add checks to prevent access to invalid or deallocated memory.
• Low · Unvalidated Template Parameters — include/EASTL/ (all files). As a template library, EASTL relies on template parameters from user code. Malformed or intentionally malicious template arguments could potentially cause unexpected behavior or expose internal implementation details. Fix: Add static assertions and compile-time checks to validate template parameters. Document expected behavior and constraints clearly.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.