В C++ выпиливают поддержку RAW-указателей.

X-Shar,
> все проблемы с безопасностью не в языке, а в проектировании самой операционке
и в языке, и в железках, и в коде, и в системе

 

проблема переполнения буфера без всяких танцев с бубном решается и на Сях. Но с точки зрения бизнес-модели коммерс софта необходимо делать такие баги в коде.. просто необходимо. ибо оное позволяет..

1. использовать концепцию "устаревшего" софта для продажи "новых" версий.
2. шпиЁнить.
3. зарабатывать на тех. поддержке.
++++
кстати, с железками та же батва: производительность топовых версий процев/видюх/.. может получаться сугубо на основе магии микрокодов

 

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

 

вот хорошее видео о том, как сложно сделать си-подобный язык мемори-сейф:

 

И что ? Много чего сложно.

В немецком не силён, так просмотрел слайды, ну-блин вы если позиционируете себя профи (Это не лично к вам, а в целом), то будьте любезны изучить язык, если вы студент и без опыта, то развивайтесь. Касяки программистов, сваливать на язык, который является инструментом, как-то странно. ИМХО.

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

В любом случае лично мне без разницы в чём кодить, если требования заказчика будет раст, то пожалуйста изучу и его. Пока-что не одного проекта на нём не видел.

На аде программировал немного, непонравилось, скажу что очень не понравилось. Лучше-уж си !

 

В чём польза списка неопределённых поведений?

 

Там вроде как английский.

 

Легче сделать статический анализатор кода, там-где это возможно.

Да, глюкануло что-то.

 

Открыл. Первый пункт: «A ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated». Всё равно придётся лезть в соответствующие тематические пункты за выяснением, что там shall, а что shall not.

Неопределённое поведение это не только то, что вскользь (или не вскользь) упоминается, а ещё и то, что не определено явно. Так или иначе, для того, чтобы узнать, как работает та или иная конструкция, надо смотреть в тематический пункт. А неопределённость поведения выводить из того, что там не определено, даже если явно не написано, что наступает неопределённое поведение.

В общем, судить по критерию наличия (неполного?) списка явно указанного неопределённого поведения о качестве стандарта для меня выглядит странным. Стандарт C++ написан гораздо более ясно и подробно. Стандарт C после него читать неприятно.

 

стандарт, который в явном или неявном виде допускает такие вещи как неопределенное поведение - имхо существовать не должен, т.к. это не стандарт, это #### отписка ...

 

Просто язык много чего позволяет делать.

Да и как-же тогда будут задавать задачки, которые любят задавать всякие организации на собеседованиях ?

Пример инкремент ++ безопасный оператор ?

ОК, что будет если зделать так:

i=++i + 1;

Или что будет, если сделать так:

int F(void)
{
****
}
int main (void)
{
return F();
}

Вообще, есть несколько подходов в том-же "безопасном программировании":

1. Первое ограничение языка на уровне стандартов, например существуют те-же стандарты "MISRA-C" и т.д.

Но проблема, что есть ещё специфика проектов, вот ещё пример.

Стандарт оговаривает, только две формы main:

int main(void) { /* ... */ }
int main(int argc, char *argv[]) { /* ... */ }

А если в силу ряда причин мне нужно отказаться от main и использовать где-то точку входа entry (часто это бывает нужно при "холодном старте" при "оживлении" какой-нить желлезки).

Компилятор позволит это сделать, но последствия лежат уже на программисте.

2. Можно ограничивать опасные операторы, типо там memcopy и т.д. средствами компилятора, тупо он не собирёт, пока не напишешь unsafe.

Но опять-же писать постоянно unsafe и в чём смысл ? Тогда нужно что-бы низкий уровень проектировал, ну мега-крутой чел.

А все остальные использовали уже сам язык, без unsafe, толкько тогда будет может-быть толк в этом, но не всегда возможно такое.

А про то-что из-за языка си появляются всякие уязвимости, это неверное суждение. В том-же Java не меньше уязвимостей и утечек памяти.

Всё это не смотря на хваленые "сборьщики мусора" и т.д.

 

Он требует поддерживать эти 2 формы. Но позволяет реализациям поддерживать и другие формы.

Стандарты C и C++ оговаривают 2 окружения исполнения программ: hosted и freestanding. main является точкой входа в hosted-окружении. Что происходит во freestanding-окружении — это implementation-defined.

Тут нет неопределённого поведения, это implementation-defined — ответственность на implementation. =)

 

В си может не быть майна.

В стандарте си, как-раз говорится что это будет неопределенное поведение. Могу дать страницы С99 если не верите.

В С++ незнаю как-там, особо не читал стандарт.

 

Что-бы не искать:

Да и речь больше про-то, что язык много-чего даёт делать, не всегда нужного. А с другой стороны это может-быть нужно.

Если ограничивать, средствами компилятора, например как в том-же C#, Java и т.д. тоже не всегда хорошо.

Только это хотел сказать, может не самые хорошие примеры привёл.

Короче в каждом языке свои нюансы, но мне непонятно такое негативное отношение к C/С++.

 

они носят в основном сугубо надуманный характер. а так == Ся}{@ + вставки на Асме (по мере надобности) есмь куль.

 

Я специально писал, что между hosted и freestanding есть разница.