new | show | ask | jobs Github

sirwhinesalot 4 days ago

Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes

f(int n, int a[n])

Actually do what it looks like it does. Sigh

▲

veltas 4 days ago | parent | next [-]

You can do f(int n, int (*a)[n]) and it does what it looks like, since C99.

https://godbolt.org/z/8dfKMrGqv

▲

sirwhinesalot 4 days ago | parent [-]

That's an entirely different thing (VLAs)

▲

veltas 4 days ago | parent [-]

There's no VLA in my example.

▲

sirwhinesalot 4 days ago | parent [-]

Your example doesn't do any bounds checks, it just lets you get the sizeof. And the reason the sizeof works is the VLA infrastructure (which is not supported by MSVC so it won't compile the code).

What I want is -fbounds-safety from clang.

	▲	navi-desu 3 days ago \| parent [-]
		it does do bounds checks if you -fsanitize=bounds, in gcc at least (and msvc is stuck on partial c11 support to this day, so imo, i don't quite think it's a fair target when comparing things to new features anyway)

▲

uecker 2 days ago | parent | prev | next [-]

You can just define a span type yourself: https://uecker.codeberg.page/2025-07-02.html

What new clang feature are you talking about?

▲

sirwhinesalot 2 days ago | parent [-]

-fbounds-safety

	▲	uecker 2 days ago \| parent [-]
		This works with new attributes as far as I know.

▲

WalterBright 4 days ago | parent | prev | next [-]

https://www.digitalmars.com/articles/C-biggest-mistake.html

You're welcome!

▲

miropalmu 4 days ago | parent | prev | next [-]

What do you mean no slice/span type?

https://en.cppreference.com/w/cpp/container/span.html

Or if you want multidimensional span:

https://en.cppreference.com/w/cpp/container/mdspan.html

▲

sirwhinesalot 4 days ago | parent [-]

C, not C++. Also span had no bounds checking until the introduction of .at() in C++26, which was a very silly thing to do so late in an age where the white house was asking people to use memory safe languages.

▲

TuxSH 4 days ago | parent | next [-]

> Also span had no bounds checking

While there was no reason not to have .at(), lack of bound checks by default isn't a bad thing, as inlined bound checks have the potential to highly pessimize code (esp. in loops); also standard library hardening is a thing.

IMO there's much more value to be had in migrating C code (and pre-C++11 code, too) to C++ (or Rust, depending on one's tastes); RAII - that is to say, the ability to automatically run destructors on scope exit - and in particular shared_ptr/unique_ptr/bespoke intrustive pointers drastically reduce the risks of use-after-free

▲

sirwhinesalot 4 days ago | parent [-]

I like how it's handled in Herb's cpp2/cppfront. If the type implements certain methods (like size()), and you turn on bounds checking, then the indexing operations (which are unsafe) are wrapped in i < c.size() ? c[i] : <throw or abort>.

This way the indexing operation itself doesn't need to have bounds checks and it's easier for the compiler to optimize out the checks or for an "unchecked" section to be requested by the programmer.

▲

aw1621107 3 days ago | parent [-]

> I like how it's handled in Herb's cpp2/cppfront. If the type implements certain methods (like size()), and you turn on bounds checking, then the indexing operations (which are unsafe) are wrapped in i < c.size() ? c[i] : <throw or abort>.

For what it's worth, something similar was proposed in the C++26 core profiles paper [0] and that particular bit got some pushback. From a reponse paper [1]:

> The paper’s suggested approach includes adding bounds checking to containers solely based on a duck-typed deduction using the availability of operators and member functions without knowing for sure what purpose the container serves, what those members do, or even whether the class is, in fact, a container at all. [P3081]’s proposal would cause a wide variety of existing, perfectly valid code to fail unpredictably at run time:

> — Containers that are not zero-indexed

> — Sparse containers

> — Map-like types the compiler cannot detect as being map-like

> — A two-color image where size() is in bytes but for which indexing is by pixel (i.e., by bit)

> — Ring-like containers

> — Containers that automatically grow.

> [P3081] also fails to consider that some library vendors already (and will continue in the future to) choose to put contract preconditions on their operator[], which would result in double and possibly inconsistent checking.

[0]: https://wg21.link/P3081

[1]: https://wg21.link/P3543

	▲	sirwhinesalot 3 days ago \| parent [-]
		Interesting, thanks for sharing!

▲

miropalmu 4 days ago | parent | prev [-]

Oh. Makes sense. My bad.

▲

pjmlp 4 days ago | parent | prev [-]

Strange are the ways of security in WG14.