>> Java написана на C/C++, поэтому в ней полно дыр. Очевидно и логично.
> Логика жабиста: во всем виноваты ... нет, не программисты. Си и плюсы
> во всем виноваты, о как.Потому что ЯП C/C++ допускают использование памяти небезопасным способом даже из другого потока — что и продемонстрировано уже миллион раз. Это на уровне ДНК конкретного языка и лечится только сменой ЯП.
> Вот это я понимаю, ламерство.
Понимай как хочешь. Как был упёртным синюшником, так и проживёшь им до старости. А там уж маразм прихватит — не до других концепций программирования будет.
> Впрочем,
> в openssl есть ламерство и на уровне чистейшей алгоритмики, вообще без
> привязки к сям и плюсам. Ну вот например, почему криптографическая либа,
> поюзав память, вообще не чистит ее после юзежа?
Наверно потому, что в C/C++ нет возможности определить, понадобится эта память ещё раз или нет — лучше перестраховаться, чем нарываться периодически на NullPointerException (или что там у вас обозначает NPE: Error, "сливай воду — программа выполнила недопустимую операцию и будет свалена в кору", "память не может быть Read"?).
> Ах, авторы раздолбаи и не парятся?
Да разработчики на C/C++ что и делают, так это парятся, как бы их поделия были устойчивыми и не ловили NPE на ровном месте — там, где другие языки давно ушли по эволюционной лестницы от смарт-поинтеров и null-терминейт массивов с алгоритмами Шлемиля к чётко определённым структурам данных заведомо известных типов без всяких оверхедов на RTTI.
> Ах, еще и malloc перехватили, чтобы система на
> могла поумничать. Замечательно. Правда такое по смыслу долбоклюйство можно повторить на
> любом ЯП, а экспонаты с GC еще и помогут наступить на
> грабли дюжиной неочевидных способов, прихранив ключи в памяти еще на полчасика,
> хотя об этом никто не просил. Ведь GC лучше знает когда
> ключ протух, правда?
Ты Java Memory Model изучил, чтобы такую чепуху городить здесь?
