pointers yay!

[wizzard]

еще раз убедился, что софт, претендующий на сколько-нибудь надежность (при больших размерах codebase) писать на С/C++ не стоит.

См. красиво и детально описанный срач на http://avva.livejournal.com/2323823.html, а также коммент http://avva.livejournal.com/2323823.html?thread=78031215#t78031215

Comments

[justy-tylor.livejournal.com]

В надёжном софте не используются напрямую стандартные библиотеки C/C++. Потому что сегодня этот софт на PC, а завтра в прошивке телевизора.

[wizzard]

ну в общем да, но вообще такая модель памяти даже при обертках и контрактах может сильно течь((

[http://users.livejournal.com/_windwalker_/]

Ну а что, такой обыкновенный адский ад от линуксоидов. Хотя Линус Торвальдс - порадовал.

[justy-tylor.livejournal.com]

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

И проблема с glibc/memcpy это тоже люди. Которые пишут библиотеки, компиляторы, виртуальные машины, и ещё много чего для разных языков. Хотя лучше бы ничего не писали.

[bik-top.livejournal.com]

> еще раз убедился, что софт, претендующий на сколько-нибудь надежность (при больших размерах codebase) писать на С/C++ не стоит.

По-моему, описанная проблема C/C++-независима. Что не опровергает твоего вывода :)

По сабжу: имхо, разработчики libc должны волевым решением «пропатчить» (дополнить, ужесточить) свою спецификацию, закрепив де-юро в ней те предположения, на которые закладываются де-факто многие разработчики. Такой патч стандарта не будет ломающим, т.е. код тех разработчиков, которые использовали официальную спецификацию (в частности, не закладывались на неопределённое поведение), не перестанет ей удовлетворять.

Далее, если самим разработчикам libc так уж необходим оптимизированный вариант, заводят свою «приватную» (насколько это достижимо в Си) версию функции memcpy, которая выбирает стратегию копирования в зависимости от архитектуры и не выполняет проверок (они всегда могут переложить гарантию удовлетворения предусловий на вызывающую сторону, так как это они сами и есть). И пусть используют эту версию в хвост и в гриву. Если хотят предоставить доступ к подобной оптимизации публике, делают ещё одну (нестандартную) версию безопасной функции memmove с проверкой аргументов и вызовом private_memcpy_optimized_unsafe.

[aka-rider.livejournal.com]

Я понимаю (но не поддерживаю) разработчиков libc, я тоже не хочу видеть в своем коде заплатки от чьего-то кретинизма. Хотя я бы сделал падение в debug - аргументы, особенно приходящие извне, нужно ассертить параноидально и нещадно.

[aka-rider.livejournal.com]

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

Кстати, пример очень хороший: по факту баг же во флеше :)

[cd-riper.livejournal.com]

> писать на С/C++ не стоит

кэп утверждает, что нет такого языка.
есть С и есть C++, два языка совершенно разного уровня.

[mata.livejournal.com]

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

[belnetmon.livejournal.com]

Спасибо за ссылку, порадовало!

[kunaifusu.livejournal.com]

+1
Стандартные библиотеки - для примеров в книжках и студентам лабы писать. "Оптимизировать" их вообще за гранью добра и зла - они бы еще printf соптимизировали чтобы он в два раза больше буков печатал.
Пример вообще не про пойнтеры, а про то, что будет с языками, у которых билиотеки в 1000 раз больше чем у С и все стандартные, когда они доживут до возраста С.

[dmitri-pavlov.livejournal.com]

И на чём же предлагается писать код большого размера, претендующий на надёжность?

[ti-ua.livejournal.com]

Подозреваю что на жабе :)

[wizzard]

BitC, например. (Я знаю что он not quite production-ready)

[dev-zzo.livejournal.com]

Нет, на чём же писать его прямо сейчас? Вот у нас выход девайса следующего поколения для N вендоров, которому внутри нужна прошивка для управления, скажем, 128Гб флэша. Какие ваши предложения? Подождать, пока кто-то где-то допилит своё творение до production-ready? (а пруф-то где, что оно ready?..)
Серьёзно. Для эмбеда и многих других случаев альтернатив совсем немного.

Ассерты и проверки *принципиально* отличаются

[bik-top.livejournal.com]

> аргументы, особенно приходящие извне, нужно ассертить параноидально и нещадно.

Нет. Аргументы, приходящие извне, нужно полноценно проверять. Ассертить можно аргументы «приватных» функций, контекст вызова которых полностью контролируется «ассертящей стороной». Условно говоря (на C#):

// Метод API, вызов которого нельзя контролировать (аргументы приходят из «недоверенной зоны»).
public void Foo(int x)
{
  // Проверка на usage error. 
  if (x < 0)
    throw new ArgumentOutOfRangeException(...);
  
  FooUnsafe(x);
}

// Метод реализации, вызов которого осуществляют только авторы библиотеки (аргументы приходят из «доверенной зоны»).
private void FooUnsafe(int x)
{
  // Проверка на logic error.
  Debug.Assert(x < 0, ...);
  
  ...
}

Если падает первая проверка, значит виноват пользователь. Исправление будет в пользовательском коде, в месте вызова.
Если падает вторая проверка, значит виновата библиотека. Исправление должно быть в библиотечном коде.

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

Re: Ассерты и проверки *принципиально* отличаются

[aka-rider.livejournal.com]

Да, я неправильно выразился.
Я имел в виду, что в случае с memcpy аргументы по сути корректные.

Re: Ассерты и проверки *принципиально* отличаются

[http://users.livejournal.com/_winnie/]

В Си нет исключений, а вызов abort - нехорошо для пользователей.

[(Anonymous)]

http://code.google.com/p/nativeclient/issues/detail?id=245

An apparently harmless refactoring of code in Google’s Native Client introduced an undefined behavior that subverted the fundamental sandboxing guarantee. This is pernicious because the (flawed) check is sitting right there in the source code, it is only in the compiler output that the check is a nop. If their regression tests used our tester, this problem would have almost certainly been caught right away. (http://blog.regehr.org/archives/508)

[wizzard]

Ага, я это читал