On Sat, 30 Aug 2025, 00:55 Levo D via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Fri, Aug 29, 2025 at 04:16:36PM -0700, Oliver Hunt wrote:
> >
> >
> > > On Aug 29, 2025, at 2:43 PM, Levo D via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> > >
> > > The goal of my proposal is to have all bounds be checked at compile
> time. If I were including containers, the check would be for all containers
> (and arrays).
> > > I haven't seen "hardened preconditions," but glancing at P3471R0, it
> looks like it's a runtime check, which isn't my goal.
> >
> > If the bounds and index are known constants at runtime the will be
> removed. If the bounds and/or index are not known/guaranteed the check
> _must_ be at runtime. That’s fundamentally unavoidable.
> >
> > > There isn't anything I could add to that. It'd be helpful if that
> proposal went through, since there might be a lot of changes inside a code
> base for access to be provably in bounds.
> > > Off the top of my head, there might not be too many changes in my
> current one and one for containers.
> >
> > It sounds like what you want is a _dianostic_ for trivial cases, which
> is already present in clang (it’s a warning by default, but you can turn it
> into an error with -Werror=array-bounds).
> >
> > Slices as you’re proposing aren’t like to happen because the path to
> memory safety requires moving away from C arrays and pointers as they
> simply do not have bounds information, and in most cases the information
> available can't be relied on - this is why despite their best efforts
> -fbounds-safety can easily require quite a lot of annotations.
> >
> > The correct thing to do is use things like std::span and similar.
>
> The proposal has code that gcc will compile that goes out of range with a
> literal with no warning.
>

Compiler warnings can be improved.


Some people don't use std (embedded and games), so I would rather have
> array support so they have some safety
>

Warnings that work for std:: span can also work for gsl::span and foo::span.

Arrays are a dead end.

The proposal has text on how to check if a runtime variable is always in
> range at compile time (using control flow)
>
>
> > > The harder part is stating when a container shouldn't have a bounds
> check (unless I should explicitly name all the containers that should have
> it).
> >
> > No - if you know the bounds of an object it is _always_ broken to access
> out of the bounds.
>
> There's code showing that compilers will allow it, even when it's a
> literal and size is known.
>

And you've also shown that your array casting code is invalid, so compilers
need to change either way: either we add better warnings that work for a
variety of cases including std::span, or we change the type system and
compilers implement the new rules.


> > > A map where people may want mapVar[-123] to return a value shouldn't
> be checked,
> >
> > I’m not sure what you mean? Do you mean std::map<int, ..> or similar?
> There would not be a bounds check for that: it’s a map, not an array?
>
> Maybe the correct solution is an attribute, which isn't automatic. I was
> talking about what if the proposal was for containers, and if there was an
> automatic way to apply checking, but now I think that's likely the wrong
> move.
> I agree that it doesn't make sense for map to be bounds checked. If I had
> sat on the email, I would have known it'd be a distraction to the
> conversation.
> An attribute that users can throw onto their own containers is probably
> the right move.
>

GCC already has this for C code (introduced for kernel data structures):

https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Common-Variable-Attributes.html#index-counted_005fby-variable-attribute

I already want to extend that to be usable in C++ to make use of it in span.



>
> > > although I'm unsure if people want me to include a case for maps where
> we need to check if a key exists before using it that way.
>

Of course not. map::operator[] has no precondition on the key.


>