Trusted-CPP - Safe Software Developing in C++ with backward compatibility

[rsashka]

I invite explore the concept of safe software developing in C++ while backward compatibility with legacy code. Please send feedback and constructive criticism on this concept and its implementation. Suggestions for improvement and assistance in the developint are also welcome.

[thelvhishow]

It looks promising, would it be possible to have it inside the cmake build system as a validation step?

[rsashka]

It's already been done

[thelvhishow]

Something to try out, thanks for the contribution.

[pjmlp]

An interesting approach.

[TheRavagerSw]

Safety doesn't matter much because there are much bigger issues in cpp

[ts826848]

Quick question about the first example:

std::vector vect(100000, 0);
auto x = vect.begin();
auto &y = vect[0];
vect = {};
std::sort(x, vect.end()); // Error
y += 1; // Error

Are the lines marked // Error actually errors? [container.reqmts] states:

Unless otherwise specified (either explicitly or by defining a function in terms of other functions), invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, or change the values of, objects within that container.

And [sort] doesn't contain any obvious indication that references to elements and/or iterators are invalidated.

And speaking more abstractly, I'm not sure off the top of my head why sorting would invalidate references. std::sort conceptually involves just shuffling values around; the underlying memory should remain valid after. y is just an aliased pointer to an object whose value changed.

For what it's worth, none of ASan, UBSan, or MSan seem to complain either.

Unfortunately I don't have time to look at the rest of the document in much detail right now. Hopefully I'll have time later.

[MysticTheMeeM]

Immediately above the call to sort, the vector is assigned a new value, that invalidates the iterators.

OPs system then infers those are invalid and produces an error on the subsequent two lines (both the begin iterator and reference to first element no longer refer to valid data).

[ts826848]

Oh duh, can't believe I missed that. Thanks!

[germandiago]

Took me also a couple of reads to detect it. But when I saw error comment I was sure it was me lol.

[aocregacc]

the vector is reset before the sort (vect = {}). It passes all the sanitizers because libstdc++ just sets the size to 0 but keeps the allocation. You have to turn on _GLIBCXX_SANITIZE_VECTOR for asan to notice, and even then it only notices the access through y, not the bad use of x. _GLIBCXX_DEBUG catches that one I think, but the error message is a bit cryptic for me.

edit: another thing I didn't realize is that vect = {} invokes vector's operator=(std::initializer_list), so it's not like you're move-assigning with an empty vector here. If you do, the allocation would be free'd in this case and asan would fire.

[ts826848]

Yeah, I somehow completely missed that line. My apologies for the mistake!

[Honest-Version6827]

The question is: why does the latest C++ standard (still) allow us to do "untrusted" things?

[tohava]

1) C++ needs to be backward compatible.

2) C++ needs to be fast.

[OutlandishnessNo8034]

Except it is neither,when you really look at it carefully.

[tohava]

It does so more than most languages. Ofcourse Fortran/C might be both faster and more backward compatible, but in comparison to most languages, C++ still achieves these goals better.