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

Тема в разделе "LANGS.C", создана пользователем im., 3 апр 2018.

Метки:
  1. unc1e

    unc1e Active Member

    Публикаций:
    2
    Регистрация:
    28 июл 2017
    Сообщения:
    287
    X-Shar,
    > все проблемы с безопасностью не в языке, а в проектировании самой операционке
    и в языке, и в железках, и в коде, и в системе
     
  2. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.076
    проблема переполнения буфера без всяких танцев с бубном решается и на Сях. Но с точки зрения бизнес-модели коммерс софта необходимо делать такие баги в коде.. просто необходимо. ибо оное позволяет..

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

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
    ну канеш дело в операционке, в браузере, во флеше, в джаве, в мелкомягком офисе, в пдф-ридере и еще огромной куче уязвимого софта, написанного сишечке и плюсах...
     
  4. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
    вот хорошее видео о том, как сложно сделать си-подобный язык мемори-сейф:
     
  5. X-Shar

    X-Shar Active Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    354
    И что ? Много чего сложно.

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

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

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

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

    CurryHowardIsomorphism Member

    Публикаций:
    0
    Регистрация:
    13 май 2017
    Сообщения:
    97
    В чём польза списка неопределённых поведений?
     
  7. CurryHowardIsomorphism

    CurryHowardIsomorphism Member

    Публикаций:
    0
    Регистрация:
    13 май 2017
    Сообщения:
    97
    Там вроде как английский.
     
  8. X-Shar

    X-Shar Active Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    354
    Легче сделать статический анализатор кода, там-где это возможно.
    Да, глюкануло что-то. :)
     
  9. CurryHowardIsomorphism

    CurryHowardIsomorphism Member

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

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

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

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.241
    стандарт, который в явном или неявном виде допускает такие вещи как неопределенное поведение - имхо существовать не должен, т.к. это не стандарт, это #### отписка ...
     
    Последнее редактирование модератором: 20 апр 2018
  11. X-Shar

    X-Shar Active Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    354
    Просто язык много чего позволяет делать.

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

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

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

    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 не меньше уязвимостей и утечек памяти.

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

    CurryHowardIsomorphism Member

    Публикаций:
    0
    Регистрация:
    13 май 2017
    Сообщения:
    97
    Он требует поддерживать эти 2 формы. Но позволяет реализациям поддерживать и другие формы.

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

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

    X-Shar Active Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    354
    В си может не быть майна. :)

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

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

    X-Shar Active Member

    Публикаций:
    0
    Регистрация:
    24 фев 2017
    Сообщения:
    354
    Что-бы не искать:
    Да и речь больше про-то, что язык много-чего даёт делать, не всегда нужного. А с другой стороны это может-быть нужно.

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

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

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

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.076
    они носят в основном сугубо надуманный характер. а так == Ся}{@ + вставки на Асме (по мере надобности) есмь куль. :)
     
  16. CurryHowardIsomorphism

    CurryHowardIsomorphism Member

    Публикаций:
    0
    Регистрация:
    13 май 2017
    Сообщения:
    97
    Я специально писал, что между hosted и freestanding есть разница.
     
    X-Shar нравится это.