одним компилятором для С11/С17 стало больше

С чего бы? sizeof для них работает, отдельно хранить длину тоже можно.

Размер свободного места в стэке по-лёгкому не узнать. Учёт размера vla-то дело ясное.

Ну так то стек вообще штука очень непредсказуемая.

char buffer[1024 * 1024];

Тоже вполне может упасть или не упасть, особенно если программист не подумает и сделает рекурсию в функции с такой локальной переменной.

Тут только делать проверку на некие разумные значения (не создавать на стеке что-то больше нескольких килобайт).

Я не говорю, что VLA штука абсолютно безобидная, но в С/C++ есть 100500 таких же штук, при использовании которых надо думать. И одной больше, одной меньше нет разницы.

Тут только делать проверку на некие разумные значения

О том и речь. В рамках языка нет чёткого критерия.

не создавать на стеке что-то больше нескольких килобайт

Для слабых МК уже тяжеловато.

Я не говорю, что VLA штука абсолютно безобидная, но в С/C++ есть 100500 таких же штук, при использовании которых надо думать. И одной больше, одной меньше нет разницы

Microsoft — это лидеры в обезопасивании сей. То есть, это не только VLA, там целый опциональный стандарт есть. Они ловят UD в контейнерах, переполнения стэка, заменяют опасные строковые функции на функции с проверкой границ, и тот же malloca, который хоть и не проверяет границу стэка, но ограничивает размер выделяемой памяти.

Если опасных вещей много — это не повод перестать уменьшать их число.

Microsoft — это лидеры в обезопасивании сей

Ору в голосину (с)

проблема в том что это расширение де факто у всех и стало стандартом де факто

Microsoft — это лидеры в обезопасивании сей

Ору в голосину

Над чем? Над тем, что есть какие-то другие лидеры, или над тем, что не обезопасили на самом деле?

Не ори, почитай тут:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt?view=vs-2019

Не понимаю, зачем нужен этот проприетарный компилятор, если есть целых два открытых полнофункциональных компилятора от разных групп разработчиков. Разве что, что-то завязанное на его нестандартные фичи собирать.

Хотя вот выше пишут, там есть наработки по безопасному программированию. Есть какое-нибудь сравнение, что может этот комптлятор в сравнении с конкурентами?

класический мвц-онли код... не что б попатчить стандартные функции... непортабельное говно одним словом...

класический мвц-онли код… не что б попатчить стандартные функции… непортабельное говно одним словом…

Вообще-то это всё в стандарте С17(Annex K — Bounds Checking Interfaces), правда опциональная поддержка у этих интерфейсов. И glibc и bsd libc забили. Вот что пишут в комитете С.

Available Implementations

Despite the specification of the APIs having been around for over a decade only a handful of implementations exist with varying degrees of completeness and conformance. The following is a survey of implementations that are known to exist and their status.

While two of the implementations below are available in portable source code form as Open Source projects, none of the popular Open Source distribution such as BSD or Linux has chosen to make either available to their users. At least one (GNU C Library) has repeatedly rejected proposals for inclusion for some of the same reasons as those noted by the Austin Group in their initial review of TR 24731-1 N1106]. It appears unlikely that the APIs will be provided by future versions of these distributions.

https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

https://gcc.gnu.org/wiki/C11Status

Bounds-checking (Annex K) [Optional] Library issue (not implemented)

https://sourceware.org/legacy-ml/libc-help/2019-01/msg00036.html

Date: Wed, 16 Jan 2019 17:06:22 +0100

Есть какое-нибудь сравнение, что может этот комптлятор в сравнении с конкурентами?

Из того что я знаю:

Он поддерживает:

1. C++/CLI

2. C++ AMP

3. SAL

4. Автопараллизацию и автовекторизацию

А также с Visual Studio 2015 поддержка стандарта С++ стала приоритетом. С++20 скорее всего будет раньше всех поддерживаться компилятором от Microsoft. Обещают до конца 2020 года.

Вот небольшая презентация с последнего cppcon: https://yadi.sk/d/RWvvkVf3lktCpg

Мне нравится SAL, хотя с другой стороны если всё аннотировать, то лучше писать на Rust :)

Случайный код скорее всего будет быстрее на Clang. Но Clang не даёт тестировать разные подходы, так как пытается делать как «лучше» и часто для разного кода генерирует одинаковый ассемблер.

вот пример: https://godbolt.org/z/PEPdKs

Автопараллизацию и автовекторизацию

Это давно есть в других компилятор. Остальные три фичи - какая-то муть.

вот ещё не плохой ролик про компиляторы: https://youtu.be/ysaBmhMEyUg

И я их понимаю. Я и себя понимаю ибо в свое время имплементировал такое же АПИ для проектных нужд - столько говна наелся.
Идея-то звучит «хорошо» если просто со стороны посмотреть, но на практике все не так хорошо. Очень часто важен контекст операции и _s его не умеет и не понимает. Зато ложную безопасность предлагает. Такие дела...