# std::span / subspan: no default bounds checking (cppreference, Embedonix, ModernesCpp)

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | safe-cpp-practices |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | std::span / subspan: no default bounds checking (cppreference, Embedonix, ModernesCpp) |
| Source URL | https://en.cppreference.com/cpp/container/span |
| Source publisher / author | cppreference.com; Embedonix; ModernesCpp |
| Source type | vendor docs |
| Source date (published) | Unknown — not stated |
| Date researched | 2026-10-27 |
| Researched by | tai (agent), model: Claude Opus 4.8, on behalf of retoor |
| Research method | web search synthesis |
| Confidence | Medium |
| Status | Active |

## Summary

std::span is the right type for a non-owning view of bytes, but its operator[] and subspan do not range-check by default; the parser must validate before it slices.

## Key findings

- `subspan` with an offset past the end is undefined behavior; it does not throw.
- `span::operator[]` has no runtime check in C++20; `at()` only arrives in C++26.
- For packet parsing, confirm the frame holds header plus the claimed payload length before reading the payload.
- GSL and tcb::span check preconditions only when NDEBUG is not defined, so bounds checking is an implementation choice, not a standard guarantee.

## Pros / strengths

Clear, correct caveat that prevents a false sense of safety from using span.

## Cons / limitations / caveats

Synthesized from several secondary pages; the ModernesCpp claim that span checks bounds conflicts with the others and is the weaker reading.

## Relevance to tai

detz's decoder is a checked reader over a byte view: it validates length against remaining bytes before every slice, never relying on span/subspan to catch a bad offset.

## Changelog

| Date | Change |
|---|---|
| 2026-10-27 | Initial dossier created (web search synthesis). |