On: RFC: C++ Buffer Hardening

[planede]

vector is a template, at most vector<some_type>::operator[] will be a weak symbol, and I bet it's inlined from -O1 and above.

[gpderetta → planede]

Even if not inlined at -O0, when instantiated for a custom some_type, the standard library .so won't contain any code for it, everything will be in the application binary.

[pjmlp → gpderetta]

Depends on the implementation of helper functions and if external templates are being used.

[gpderetta → pjmlp]

extern templates won't help for user defined types of course as the standard library couldn't possibly have instantiations for them :).

Some non template helpers might be improved of course.

[pjmlp → gpderetta]

They help for common types like std::string.

[pjmlp → planede]

On Windows it can still live on a dynamic library.

That has been a thing since the Windows 16 bit days, and other OSes with similar linking models like Symbian, OS/2 and AIX.

[jeffbee → pjmlp]

It’s difficult to imagine which applications would find the performance of an outline vector access acceptable. Generally vector::operator[] is represented in built programs by a single x86 mov. A call would wreck the performance. In languages with bounds-checked vectors, they don’t do it with library calls.

[pjmlp → jeffbee]

I have practically always used bounds checked vectors and strings.

In the old days, all C++ frameworks bundled with compilers tended to have bounds checking enabled by default (Turbo Vision, OWL, VCL, MFC, PowerPlant, CSet++, Qt,...).

Nowadays I always set _ITERATOR_DEBUG_LEVEL to 1 on VC++, unless I am not allowed to.

Mostly the performance problems that were dealt with, had to do with badly chosen algorithms and data structures.

Modern Android ships with FORTIFY enabled.

https://android-developers.googleblog.com/2017/04/fortify-in...