Skip to content

Guard 64-bit iterator size static_asserts for non 64-bit targets#217

Open
adityasingh2400 wants to merge 1 commit into
teslamotors:mainfrom
adityasingh2400:fix-128-portable-iterator-size-asserts
Open

Guard 64-bit iterator size static_asserts for non 64-bit targets#217
adityasingh2400 wants to merge 1 commit into
teslamotors:mainfrom
adityasingh2400:fix-128-portable-iterator-size-asserts

Conversation

@adityasingh2400

Copy link
Copy Markdown
Contributor

Problem

The integer range iterator tests assert the exact byte size of several iterator types with hardcoded values that assume a 64-bit data model, for example:

static_assert(sizeof(IntegerRangeIterator<IteratorDirection::FORWARD, IntegerRange>) == 24);
static_assert(sizeof(CircularIntegerRangeIterator<IteratorDirection::FORWARD, IntegerRange>) == 32);

These iterators are composed of std::size_t-width members. On platforms with narrower pointers and std::size_t, such as wasm32, the iterators are smaller, so these static_asserts fail to compile. This is one of the remaining failures from issue #128 when compiling the project with emscripten, after the unrelated iterator_ two phase lookup fix in #129. The reporter confirmed these size and death test asserts were the only remaining errors.

Root cause

The asserted byte counts are valid only under a 64-bit data model. They are layout sanity checks, not portability requirements, but they were written unconditionally, so any target where sizeof(std::size_t) is not 8 breaks the build. I also verified that the sizes are not a clean multiple of sizeof(std::size_t) on 32-bit targets because of alignment of the iterator wrappers, so a per-platform recomputation would be fragile.

Fix

Wrap the size static_asserts in a defined(__SIZEOF_POINTER__) && __SIZEOF_POINTER__ == 8 guard in the three affected test files:

  • test/integer_range_iterator_test.cpp
  • test/circular_integer_range_iterator_test.cpp
  • test/filtered_integer_range_iterator_test.cpp

This mirrors the existing platform gating already used in these files, keeps the layout checks fully enforced on the primary 64-bit configurations, and skips them where the exact byte count is not meaningful. No library or runtime behavior changes, this only affects compile-time layout assertions in tests.

Verification

  • 64-bit native, where __SIZEOF_POINTER__ == 8: all three test translation units compile with -std=c++20, the guarded asserts stay active and pass.
  • 32-bit simulation with -m32, where __SIZEOF_POINTER__ == 4, reproducing the narrower wasm32 width: an isolated probe of the same asserts failed before this change with the exact errors reported in the issue, and compiles clean after, since the guard now skips them.
  • clang-format applied to all three files, the diff is format stable.

Out of scope: the EXPECT_DEATH errors under emscripten come from gtest death tests not being available on that platform, which is a gtest and toolchain limitation rather than a fixed-containers issue, so they are left untouched.

Fixes #128

The integer range iterator tests assert the exact byte size of several
iterator types using hardcoded values that assume a 64-bit data model,
for example sizeof(IntegerRangeIterator<...>) == 24. These iterators are
built from std::size_t-width members, so on platforms with narrower
pointers and std::size_t, such as wasm32, the actual sizes are smaller
and the static_asserts fail to compile.

The byte counts are only meaningful as a layout check on 64-bit targets,
so wrap them in a __SIZEOF_POINTER__ == 8 guard. This mirrors the
existing platform gating in these files and removes the false build
failures reported when compiling with emscripten, while keeping the
layout checks fully enforced on the primary 64-bit configurations.
@alexkaratarakis alexkaratarakis force-pushed the fix-128-portable-iterator-size-asserts branch from 46a04c2 to 922ae2e Compare June 16, 2026 22:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Compiling with emscripten

1 participant