LINUX.ORG.RU

Атака на пакет arrayref Rust

 , , ,


0

5

Атака на цепочку поставок: вредоносный код в crates.io через пакет arrayref

20 августа 2026 года Команда безопасности Rust (Rust Security Response Team) сообщила об обнаружении вредоносных пакетов в реестре crates.io, связанных с популярной библиотекой arrayref.

Что произошло

20 августа 2026 года в 7:15 UTC команда получила сообщение о том, что пакет proc-macro1 является вредоносным. После проверки выяснилось, что его build-скрипт загружал вредоносное ПО.

Пакет proc-macro1, а также связанные с ним proc-macro-en, aovine, arone, aronenao и tinymember были удалены из реестра.

Дальнейшее расследование показало, что широко используемый пакет arrayref был недавно перевыпущен с добавленной зависимостью от вредоносного proc-macro1, при этом последние версии были помечены как yanked. Команда удалила вредоносную версию и восстановила ранее ошибочно отозванные версии.

Аналогичным образом пострадали другие пакеты того же автора — internment и append-only-vec. По ним были приняты те же меры. Аккаунт автора заблокирован в качестве меры предосторожности. По имеющимся данным, сам автор arrayref не действовал злонамеренно — вероятнее всего, были скомпрометированы его компьютер или учётные данные. Команда пытается связаться с ним.

Что нужно сделать пользователям

Рекомендуется проверить локальные зависимости на предмет использования следующих вредоносных версий, удалённых с crates.io:

  • append-only-vec@0.1.9
  • arrayref@0.3.10
  • internment@0.8.7
  • proc-macro1, proc-macro-en, aovine, arone, aronenao, tinymember (любые версии)

Проверить наличие этих пакетов в локальном кэше можно следующей командой:

find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

Благодарности

Команда Rust поблагодарила исследователей Nextron Systems GmbH за первоначальное обнаружение проблемы и сообщение о ней, а также сотрудников, участвовавших в устранении инцидента.

>>> Источник



Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от sena

максимально совместимый безопасный си и с++.

Раст, что ли? безопасность и совместимость - взаимоисключающие требования, не будет такого никогда.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Раст, что ли? безопасность и совместимость - взаимоисключающие требования, не будет такого никогда.

Это почему же? Пусть 100% совместимости в безопасном режиме конечно не будет, но если, условно 95% кода будет работать, то и отлично. 5% постепенно переписать реально. А пока оно будет в небезопасном режиме.

sena ★★★
()
Ответ на: комментарий от unC0Rr

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

bbc69
()
Ответ на: комментарий от saahriktu

Это ещё почему? Сегодня и нейросетями переписывают. Были бы задача и оператор ИИ. Так что, проблем нет.

На нейросети одна надежда. :) Но, как я уже говорил, тогда и язык для нас кожаных не так уж важен, это уже нейросети там как-то между собой договорятся и нам сообщат. :)

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

Не будет. Вот просто не будет.

Разве что комитет это по какой-то причине намеренно не сделает. Что я тоже не исключаю, судя по его решениям.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от sena

Язык важен как для ревьюверов, так и для присылающих патчи. А в живой проект обычно приходят патчи и от живых людей. Да и мало ли что захочется переделать для самого себя, а именно для этой задачи в своё время Ричард Столлман и придумал GNU GPL.

Потому, кстати, и будут переписывать, что теперь большинство людей будут знать Rust, но не C/C++.

При этом никто не говорит, что нельзя будет писать на C/C++. Но они постепенно уходят в ту же нишу, что и Fortran с Паскалем. А на Фортране и Паскале и сегодня тоже пишут, да.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от sena

А велика ли разница переписываний на безопасный цепепе или на безопасный раст? Закопать цепепе — не использовать для новых проектов или даже новых модулей проектов существуюущих.

BruteForce ★★★★
()
Ответ на: комментарий от bbc69

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

Новый код: #include <staryi_kod.h>

А теперь обеспечь совместимость и безопасность.

unC0Rr ★★★★★
()
Последнее исправление: unC0Rr (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

Новый код: #include <staryi_kod.h>

#include <proklyatiy_stariy_kod.h>

Простите.

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

А новый пиши уже по-человечески.

bbc69
()
Ответ на: комментарий от sena

Как у тебя 95% кода цепепе начнёт безопасно работать после каких-нибудь решений комитета? После решений комитета у тебя либо НЕ будет работать 95% кода, либо, если повезёт, будет работать как раньше.

Если тебе СЕЙЧАС надо, чтобы твой цепепе был «мемори сейф» — то всё уже готово: Fil-C 0.682 — memory safety без переписывания

BruteForce ★★★★
()
Ответ на: комментарий от bbc69

Старый код от этого безопаснее как станет?

Правильно я понял предложение @sena, что надо ждать копрокорпофилов из комитетов чтобы они стандарт цепепе ещё чуточку усложнили и вот тогда заживём?

BruteForce ★★★★
()
Последнее исправление: BruteForce (всего исправлений: 1)
Ответ на: комментарий от sena

БЯМ не ставит цели, БЯМ выдаёт некоторые возможные сочетания слов из наиболее вероятных для учебной выборки. «Договорятся», «сообщат» — это ты приписываешь им намерения. Не надо так делать, это уровень Антропик и ОпенАИ: «БЯМ ВРВАЛАС И САМА ВЗЛАМАЛА ЧУЖОЙ ПРОЕКТ, НО МЫ ЕЁ В ТУРМУ НЕ ПОСАДИМ, ХАХА, ВЫ ЧТО, ОНА ЖЕ ХОРОШАЯ ПРОСТО ЗАПУКАЛАСЬ БЕДНАЯ СЛАДКАЯ, БЕГИТЕ ЧЕРТИ ВАМ ХАНА»

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

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

bbc69
()
Ответ на: комментарий от BruteForce

Мне лично без разницы, можно и похоронить. Но если создатели/держатели хотят, чтобы их язык жил, надо в него вносить изменения подобного рода.

bbc69
()
Ответ на: комментарий от bbc69

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

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

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

Именно так.

Я вижу всего два варианта: 1. закопать цпп, 2. Дать возможность писать безопасно. Чтобы неофиты писали новый код по новому, бить их палками по рукам.

Если оставить ситуацию как есть со словами: «не нужон ваш бороу чекер, нам и на сях неплохо», реализуется первый вариант со временем.

bbc69
()
Ответ на: комментарий от unC0Rr

очень просто

unsafe {
 #include <stariy_kod.h>

 call_opasniy_kod();
 
}

в расте же тоже можно вызывать внешние опасные библиотеки?

sena ★★★
()
Последнее исправление: sena (всего исправлений: 3)
Ответ на: комментарий от BruteForce

БЯМ не ставит цели…

Какая разница, как это называть. Если ты спросишь, какой язык подходит для этой задачи, она тебе ответит. Но кто-то другой не будет морочить голову, а просто напишет, «выбери подходящий язык и напиши мне серверок для транзакций и запусти его там, но чтобы безопасно зюзюзю». Потому что «а нафига»?

sena ★★★
()
Последнее исправление: sena (всего исправлений: 4)
Ответ на: комментарий от BruteForce

похоронить цепепе

сначала стоило бы похоронить си

yatazet
() автор топика
Ответ на: комментарий от BruteForce

Как у тебя 95% кода цепепе начнёт безопасно работать после каких-нибудь решений комитета? После решений комитета у тебя либо НЕ будет работать 95% кода, либо, если повезёт, будет работать как раньше.

Очень просто. Если я вызывал функцию double sin(double), почему она будет как-то иначе выглядеть в безопасном c++? Если у меня был код

std::list<std::string> sl;
sl.push_back("pruvet");

Почему он перестанет работать после решений комитета?

Да, где-то будут проблемы, но много чего заработает с минимальными переделками и можно будет сразу повесить плашку «safe 100%» на радость корпам.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 3)
Ответ на: комментарий от saahriktu

Язык важен как для ревьюверов, так и для присылающих патчи.

Пока да, пока ещё да. Впрочем ревьювить и патчить нейронки тоже умеют.

sena ★★★
()
Ответ на: комментарий от sena

в расте же тоже можно вызывать внешние опасные библиотеки?

Во-первых, вот оно, ключевое слово: в расте же можно. Расту уже не первый десяток лет, в нём уже можно. Нахрен цпп 2.0?

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

unC0Rr ★★★★★
()
Ответ на: комментарий от bbc69

Дать возможность писать безопасно.

Что значит дать возможность писать безопасно? Надо отбирать возможность писать небезопасно. Писать как угодно можно и сейчас, хоть на асме. Проблемы возникают, когда человеческого внимания не хватает, и возникает ошибка в коде. Асм съест практически что угодно, Си очень многое, какой-нибудь идрис заставит тебя доказывать все заявленные свойства кода.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Во-первых, вот оно, ключевое слово: в расте же можно. Расту уже не первый десяток лет, в нём уже можно. Нахрен цпп 2.0?

А, ну то есть можно и раст не развалился, а в с++ нельзя? Ой. У вас ус отклеился. ;)

Зачем цпп 2.0 понятно, чтобы сэкономить деньги и ресурсы. Проще подправить компилятор и стандарты, чем переписывать (или тем более выкидывать) миллиарды строк годного кода. Правда раст становится не нужен. Я тебя понимаю.

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

Так элементарно вроде бы. Если темплейт старый и небезопасный, то он будет компилироваться только внутри unsafe блока. В чём ты видишь проблему? Ты не сможешь использовать старый небезопасный template в безопасном блоке. Если же темплейт безопасен, то ты сможешь его использовать и в безопасном блоке, а если он совместим, то и в небезопасном тоже. Может я чего-то не понимаю, вроде несложно выходит.

В расте же всё это есть, можно даже сишные библиотеки вызывать. Вообще проблемы нет никакой.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 6)
Ответ на: комментарий от BruteForce

Всё что я понял из слов @unC0Rr, это что расту можно исполнять небезопасный код в unsafe блоке и даже сишные библиотеки вызывать, а изменить точно также c++ запрещено свыше. Потому что… что? Не, просто запрещено и всё.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 5)
Ответ на: комментарий от sena

Не запрещено, а никому это не нужно. Вызывать из unsafe можно уже прямо сейчас из раста. Новый цпп не совместимый со старым не нужен.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Я понял, тебе не нужен. Ну значит тебя вычёркиваем. :)

Если спрос на безопасность есть (а он вроде есть), то он нужен всем, у кого много с++ кода. Например он может понадобиться мне, если вдруг в тендерах все потенциальные покупатели начнут указывать требование «язык с гарантиями безопасности».

sena ★★★
()
Последнее исправление: sena (всего исправлений: 4)
Ответ на: комментарий от sena

Если спрос на безопасность есть (а он вроде есть), то он нужен всем, у кого много с++ кода

Ну так раст уже есть, зачем ждать стандарт c++52?

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Ну так раст уже есть, зачем ждать стандарт c++52?

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

sena ★★★
()
Последнее исправление: sena (всего исправлений: 3)
Ответ на: комментарий от sena

я показал тебе аналог,

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

trait DoubleLinked where Self:Sized {  
    type T;
    fn next(self) -> Option<Self>;
    fn prev(self) -> Option<Self>;

    // какой-то минимум для действий с элементом
    fn value_mut(&mut self) -> &mut Self::T;
}

Попытайся теперь написать подобное в полной мере на плюсах, и не забудь потом вставить обратно глаза.

zurg ★★
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от zurg

Вообще, приглядевшись к этому трейту, мы вспоминаем, что в расте уже есть итераторы. Ещё как есть. Которые быстрее чем что-либо и где-либо, и при этом удобные, с хорошей читаемостью. Плюсовое же безобразие близко не валялось. Есть или раннее STL-ное вырвиглазие, или современные Rang-и, с которыми кровь из глаз уже, конечно, уже не хлещет, а так, тихонько сочится, но тормозные. Да, чуть не забыл: и те и другие всё так же могут стрельнуть UB, и, как это водится в сишках, совершенно внезапным загадочным образом.

zurg ★★
()
Последнее исправление: zurg (всего исправлений: 2)
Ответ на: комментарий от sena

Это в индустрии нахрен не нужно никому. Яркий пример такого ненужно - carbon. Просто тратят корпоративные деньги, чтобы занять чем-нибудь сотрудников.

seiken ★★★★★
()
Ответ на: комментарий от zurg

плюсовые умные указатели тяжелее и медленнее растовых

Это правда. Плюсовый shared_ptr чуть медленнее за счёт того что он использует атомики и потому потокбезопасный, а Rc - небезопасный. Но умные указатели там не нужны, код с ними выглядит как минимум уродливо. Может быть можно придумать какой-то новый специальный тип указателя для этого случая, не знаю… Но без умных пока получается и быстрее и эффективней и понятней.

И кстати, собственно, список ты так и не показал.

Я прислал полный аналог кода (по функциональности), который прислал кто-то другой, так что претензия не ко мне. Я вообще на расте не писал никогда, это первый раз, когда я на него поглядел поближе и понял, что не надо путать туризм с эмиграцией. :)

Суть списка в операции - «перейти к следующему (и предыдущему для двухсвязного)»

Э? Одному нужно рассказывать, для чего нужен список, другому - как перейти к следующему элементу…

Ты прислал только интерфейс

fn next(self) -> Option<Self>;

Но где реализация next()? В исходном коде её нет. И как же она будет выглядеть для того списка с Rc<RefCell<>> и Weak?

С таким же успехом я могу прислать

p = p->next;

или:

auto it = list.begin();
++it;

Красиво же. Простой интерфейс ничего не говорит о сложности под капотом. Или ты про синтаксис? Так это вообще отдельная тема.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 2)
Ответ на: комментарий от seiken

Это в индустрии нахрен не нужно никому. Яркий пример такого ненужно - carbon. Просто тратят корпоративные деньги, чтобы занять чем-нибудь сотрудников.

Я согласен, конечно. С моей точки зрения без этого тоже можно прожить. Но иногда надо делать вот такую вот фигню, чтобы можно было, например, пройти тендер или сертификацию. Все участники это понимают, и те кто выставляют эти требования на тендер и те кто соревнуется, но - надо. Жизнь она такая.

Для языка важно оставаться … модным что-ли. Ну или актуальным. Отвечать на вызовы времени ещё говорят. Если в него не будет приходить молодёжь, то он может зачахнуть вместе с его последними носителями.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 4)
Ответ на: комментарий от BruteForce

И какой язык отвечает вызовам настоящего?..

Надо, конечно, говорить прежде всего про США, потому что именно там принимаются ключевые решения и по си/с++ и по расту. А там, после того как повестку подняли спецслужбы и правительство США, а потом на это наложились волны уязвимостей, обнаруженных нейронками, эта тема стала одной из самых горячих. А в области, где раньше безраздельно властвовали си/c++, раст действительно лучше всего отвечает на этот вызов современности. Другой такой большой вызов это нейросети, но тут раст вроде бы скромно себя показал. Больше ничего в голову не пришло, только 2 «вызова современности». :)

Кстати, если исключить существование какого-то заговора и этот тренд продержится достаточно долго, то по этой же логике (корпы-спонсоры находятся в основном в США, где влияют госструктуры США) си/с++ тоже должны подтянуть в этой области. Хотя не исключено и то, что все старые уязвимости обнаружат и починят, волна спадёт и эту тему успешно забудут, найдя себе новую заморочку.

И тут про нейронки добавлю. Если каждый коммит начнут проверять на уязвимости нейронками, прямо в CI/CD, то количество реальных уязвимостей снизится настолько, что неудобства от применения безопасных языков превысят всю возможную выгоду от их применения.

Зачем вообще менять си/с++, если можно просто выявлять все потенциальные уязвимости на этапе разработки?

sena ★★★
()
Последнее исправление: sena (всего исправлений: 9)
Ответ на: комментарий от sena

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

А вот это интересно. По идее, язык с безопасностью памяти из коробки как раз хорошо подходит для иишек.

Мало данных для обучения?

bbc69
()
Ответ на: комментарий от sena

shared_ptr и потому потокбезопасный, а Rc - небезопасный.

С точностью до наоборот, Rc - всегда безопасный, и потоко- тоже, тем что компилятор не даст в другой поток утащить. Худшее что может случится - упадёт с паникой, но UB не допустит. А вот shared_ptr - типичная бестолковая плюсовая фича, он не так чтобы потокобезопасный, данные всё равно надо отдельно защищать, а для всего остального он слишком тяжёлый.

Ты прислал только интерфейс

Смысл был в том что напиши, хотя бы, его.

С таким же успехом я могу прислать

Нет, не можешь. Это всё ПРИМЕНЕНИЕ реализации интерфейса. Ты потерял десятки строчек уродливой шаблонно-оопешной лапши плюс, возможно, обмазанной новомодными концептами

zurg ★★
()
Ответ на: комментарий от zurg

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

Я из-за вас скоро уже раст освою :)

shared_ptr не делает объект потокобезопасным, он делает потокобезопасным совместное управление временем жизни, за это он платит атомарным счётчиком. Rc дешевле именно потому, что Rust запрещает использовать его между потоками. Если уж сравнивать, то shared_ptr корректней сравнивать с Arc, который такой же «бестолковый» как и shared_ptr - данные всё равно надо защищать отдельно.

для всего остального он слишком тяжёлый.

Это, мягко говоря, преувеличение. shared_ptr конечно медленнее сырых указателей и unique_ptr, если его постоянно копировать, но это не значит это непременно будет значимая потеря производительности. На фоне блокировок, выделения памяти и тем более системных вызовов его стоимость может быть и вовсе незаметна. Часто его можно передавать по ссылке, тогда счётчик вообще не трогается.

Смысл был в том что напиши, хотя бы, его.

Для начала мне нужно хотя бы понять, что именно это такое. И какое это вообще имеет отношение к делу? Если я правильно понимаю, это такой класс, типа курсора, с помощью которого можно ходить по списку туда-сюда. Верно?

Я конечно могу привести аналогичный код на с++, но прежде тебе неплохо было бы объяснить, как это улучшает катастрофу с изначальным примером? Даже если на расте получается более удобный и менее многословный интрефейс, это не решает никак проблему с владением и временем жизни узлов в исходном примере!

Потом можно будет, конечно, обсудить и с++ аналог, если он кому-то нужен…

template<class T>
struct Cursor {
    Node<T>* p;

    std::optional<Cursor> next();
    std::optional<Cursor> prev();
    T& value_mut();
};
sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от sena

который такой же «бестолковый» как и shared_ptr - данные всё равно надо защищать отдельно

Не-а, с Arc ты не забудешь защитить данные, с shared_ptr тебе ничего не помешает.

Часто его можно передавать по ссылке

Указатель на указатель, замечательно, всё как мы любим. Впрочем, с Rc/Arc ничего не мешает делать так же.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Не-а, с Arc ты не забудешь защитить данные, с shared_ptr тебе ничего не помешает.

Это не достоинство Arc, это уже гарантия самого языка. Да это очень сильная сторона раста, которая избавляет от многих проблем с многопоточкой. Правда не от всех, если я правильно понимаю, от race condition уже автоматической защиты нет. То есть ситуация когда в двух тредах одновременно исполняется if(account >= 100) account -= 100; то в расте account может уйти в минус без дополнительной синхронизации и логика сломается, хотя отдельные операции с account могут быть атомарны. Но то что есть уже очень круто.

Естественно это приведёт и к тому что там, где в с++ синхронизация обеспечивается способом извне раста, например через event loop, юникс-семафором, вводом-выводом, каким-то правилом архитектурно и т.п., то в расте такой же код может не скомпилироваться, хотя он будет вполне безопасный и где-то придётся извращаться, как и со списком или использовать unsafe.

Но всё равно, иметь возможность писать гарантированно безопасный код от довольно широкой и довольно неприятной группы ошибок, пусть ценой повышенной сложности, иногда переходящей в извращения, это здорово и очень круто. Я хотел бы, чтобы такая возможность в c++ была. Главное не забывать, что у всего есть цена.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 3)
Ответ на: комментарий от sena

Вообще то есть неатомарный shared_ptr. В бусте кажется. У раста и тут нет никакого преимущества. Он нужен ТОЛЬКО там, где проектирование сведено к минимуму или отсутствует.

ckotctvo
()
Ответ на: комментарий от ckotctvo

Вообще то есть неатомарный shared_ptr. В бусте кажется. У раста и тут нет никакого преимущества. > Он нужен ТОЛЬКО там, где проектирование сведено к минимуму или отсутствует.

Да понятно, можно и самому сделать. Но разница в том, что раст не даст неатомарный использовать в разных потоках. Это плюс конечно, особенно если есть возможность включить unsafe и всё равно использовать.

sena ★★★
()
Последнее исправление: sena (всего исправлений: 1)
Ответ на: комментарий от ckotctvo

Но ява, потом питон и прочие другие тем не менее отъели у с/с++ изрядный кусок. Хотя и не похоронили конечно.

sena ★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.