On Sat, 30 Aug 2025, 11:01 Jonathan Wakely, <cxx_at_[hidden]> wrote:

>
>
> 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.
>

Also, nobody is going to pass all arrays by reference, that's another dead
end.

Instead of something completely novel (and unlikely to be accepted) for C
and C++, you should at least look at the C syntax for specifying static
bounds on an array parameter, which doesn't actually require passing by
reference (they still decay to pointers, you just provide more information
to the compiler):

void func(int a[static 2]) { }

This accepts any pointer, but tells the compiler that there are at least 2
elements in the array.



> 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.
>
>
>>