Previous Entry Share Next Entry
2016-01

pointers yay!

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

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


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

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

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

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

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

(Anonymous) April 9th, 2011
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)

wizzard0 April 9th, 2011
Ага, я это читал

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

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

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

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

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

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

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

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

Нет. Аргументы, приходящие извне, нужно полноценно проверять. Ассертить можно аргументы «приватных» функций, контекст вызова которых полностью контролируется «ассертящей стороной». Условно говоря (на 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 March 30th, 2011
Да, я неправильно выразился.
Я имел в виду, что в случае с memcpy аргументы по сути корректные.

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

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

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

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

cd_riper March 30th, 2011
> писать на С/C++ не стоит

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

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

vp March 30th, 2011
Спасибо за ссылку, порадовало!

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

ti_ua March 30th, 2011
Подозреваю что на жабе :)

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

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

  • 1
?

Log in

No account? Create an account