51–60 of 129 posts
this is amazing, counter to what most ppl think, majority of memory bugs are from out of bounds access, not stuff like forgetting to free a pointer or some such
this is amazing, counter to what most ppl think, majority of memory bugs are from out of bounds access, not stuff like forgetting to free a pointer or some such
Occasionally an out-of-bounds access pops up, but they're generally so blindingly obvious and easy to fix that it's never been the slow part of bug fixing.
template struct Slice { T* data = nullptr; size_t size = nullptr; T& operator[](size_t index) { if (index >= size) crash_the_program(); return data[index]; } }; If you're considering this extension, just use C++ and 5 lines of standard, portable, no-weird-annotations code instead.
size_t size = nullptr;
this is amazing, counter to what most ppl think, majority of memory bugs are from out of bounds access, not stuff like forgetting to free a pointer or some such
Personally, as someone in C and C++ for the last few years, memory access is almost never the root bug. It's almost always logic errors. Not accounting for all paths, not handling edge cases, not being able to handle certain combinations of user or file input, etc. Occasionally an out-of-bounds access pops up, but they're generally so blindingly obvious and easy to fix that it's never been the slow part of bug fixing…
My last memory error in C code in production was in 2018. Prior to that it I had a memory error in C code in production in 2007 or 2008.
In C++, I eventually gave up trying to ship the same level of quality and left the language altogether.
Has any progress been made on this? I remember seeing this proposal 3 or 4 years ago but it looks like it still hasn't been implemented. It's a shame because it seems like a useful feature. It looks like Microsoft has something similar ( https://learn.microsoft.com/en-us/cpp/code-quality/understan... ) but it would be nice to have something that worked on other platforms.
this is amazing, counter to what most ppl think, majority of memory bugs are from out of bounds access, not stuff like forgetting to free a pointer or some such
Personally, as someone in C and C++ for the last few years, memory access is almost never the root bug. It's almost always logic errors. Not accounting for all paths, not handling edge cases, not being able to handle certain combinations of user or file input, etc. Occasionally an out-of-bounds access pops up, but they're generally so blindingly obvious and easy to fix that it's never been the slow part of bug fixing…
Earlier quoted context omitted.
Or just do it in C. #define span(T) struct span_##T { size_t len; T *data; } #define span_access(T, x, i) (*({ \ span(T) *_v = (x); \ auto _i = (i); \ if (((size_t)_i) >= _v->len) abort(); \ &_v->data[_i]; \ })) https://godbolt.org/z/TvxseshGc
Still requires a gcc/clang specific extension (although this one I'd be very happy to see standardized)
Earlier quoted context omitted.
Or just do it in C. #define span(T) struct span_##T { size_t len; T *data; } #define span_access(T, x, i) (*({ \ span(T) *_v = (x); \ auto _i = (i); \ if (((size_t)_i) >= _v->len) abort(); \ &_v->data[_i]; \ })) https://godbolt.org/z/TvxseshGc
The fact that pointer types can't be used with this pattern without typedef still seems kinda primitive to me.
I'm skeptical this is workable... it's pretty common in systems code to take the address of a local variable and pass it somewhere. Many event libraries implement waiting for an event that way: push a pointer to a futex on the stack to a global list, and block on it.
They address it explicitly later:
> Although simply modifying types of a local variable doesn’t normally impact the ABI, taking the address of such a modified type could create a pointer type that has an ABI mismatch
That breaks a lot of stuff.
The explicit annotations seem like they could have real value for libraries, especially since they can be ifdef'd away. But the general stack variable thing is going to break too much real world code.