это может иметь смысл для развития численных методов, как думаете?
Нет ничего удивительного что если мы как то огрубили начальное состояние и не заметили там мльенького торнадо между узлами решетки для численного расчета. Пост слабоват для гиктаймз, без единой формулы о таких вещах не поговоришь. И что такое слабые решения осталось загадкой.
Почитал чуть-чуть статью (pdf).
Очередной прикол с асинхроным исполнением. Надо бы в таких случаях применять какие то алгоритмы чтобы формально доказывать корректность работы.
Вообще опасная фича что сначала загружается в регистр запрещенный участок памяти а потом уже идет проверка на то были ли на это разрешения. Похоже дело было так: реализация доступа к страницам памяти была еще с рождения х86, а потом поверх решили добавить out-of-order инструкции новым слоем, и вышло такое комбо.
Ну нелзя же вбивать в iot решето учетку к которой привязаны важные данные. Помница была статья про проверку ос самсунга, там как будто програмистов на си набирали на конференции по джаваскрипт.
Там ошибка с переполнением происходит в момент сериализации каких то блютузных структур в буфер для отправки. Так вот размер буфера выделяется где то вначале процедуры сериализации либо 64 либо 128 байт (как я глянул в коде) потом происходит его наполнение разными данными, которые являются разными структурами, через if/else и switch/case, соответсвенно заранее спрогнозировать нужный размер буфера не возможно и получаем потенциальную возможность выхода за пределы массива.
В патче теперь добавили проверку при каждой записи в этот буфер на переполнение и соответсвенно теперь по всему коду передается не только указатель но дополнительным аргуметом размер. Это является самым удобным представлением массива по мнению сишников.
Вполне возможно стандарт синего зуба предполагает фиксированный размер пакета, но доказать то что любая комбинация тех самых if/else и switch/case выдает на выходе меньше чем N байт никто не удосужился, потому что цитата "протокол bluetooth сложный". А оказывается что ребята из armis придумали как подобрать такие параметры запроса чтобы "инвариант" нарушился.
P.S. я не специальист по ядру и тем более блютузу так что все выше изложенное сказано на правах дилетанта
Каждый раз, когда поднимается тема фейковых новостей, я вспоминаю цитату Стива Джобса:
When you’re young, you look at television and think, There’s a conspiracy. The networks have conspired to dumb us down. But when you get a little older, you realize that’s not true. The networks are in business to give people exactly what they want. That’s a far more depressing thought. Conspiracy is optimistic! You can shoot the bastards! We can have a revolution! But the networks are really in business to give people what they want. It’s the truth.
Что в моем вольном переводе означает, что медиа корпорации производят кал не потому что это жидомассонский заговор, а потому что людям нравится его хавать.
А системы гугла и фейсбука с положительной обратной связью только ухудшают ситуацию.
Когда имеем дело с вводом пользователя или 3их лиц таких как сервер то надо обязательно проверять корректность ввода.
Кроме переполнения header из комента выше могу добавит проблему что не везде есть проверки что strstr находит подстроку. И дальше может быть обращение к плохому указателю.
Из моего опыта могу сказать следующее:
Чего не хватает в си++ из коробки — это нормальных многомерных массивов.
Что мешает в фортране — это отсутствие удобного ввода вывода и то что все переменные надо объявлять в начале функции.
Чего не хватает везде — это удобной интеграции с python/numpy array, потому что отдает голый указатель а не нормальный класс.
В остальном все работает одинаково имхо.
Буду рад увидеть в обсуждении конкретные примеры и опыт использования существующих инструментов.
А зачем придумали цифровые подписи?
Выглядит странно. А если ещё вдруг захочиться пропустить несколько элементов в теле цикла сделав там
i += xто всё.Да надо было
Или
enum, что лучше? Можно иsizeofно с ним легко выстрелить себе в голову.И чем это лучше обычных плюсов?
это может иметь смысл для развития численных методов, как думаете?
Нет ничего удивительного что если мы как то огрубили начальное состояние и не заметили там мльенького торнадо между узлами решетки для численного расчета. Пост слабоват для гиктаймз, без единой формулы о таких вещах не поговоришь. И что такое слабые решения осталось загадкой.
Не просто хедеров а хедеров с шаблонами и прочей “черной магией“ плюсов.
Почитал чуть-чуть статью (pdf).
Очередной прикол с асинхроным исполнением. Надо бы в таких случаях применять какие то алгоритмы чтобы формально доказывать корректность работы.
Вообще опасная фича что сначала загружается в регистр запрещенный участок памяти а потом уже идет проверка на то были ли на это разрешения. Похоже дело было так: реализация доступа к страницам памяти была еще с рождения х86, а потом поверх решили добавить out-of-order инструкции новым слоем, и вышло такое комбо.
Строки в стиле си это минное поле, каждый раз убеждаюсь.
Я тоже устал от китайских роутеров и воткнул карточку Atheros в дешевый комп на 16.04 LTS.
Ну нелзя же вбивать в
iotрешето учетку к которой привязаны важные данные. Помница была статья про проверку ос самсунга, там как будто програмистов на си набирали на конференции по джаваскрипт.Do объявлен static
Там ошибка с переполнением происходит в момент сериализации каких то блютузных структур в буфер для отправки. Так вот размер буфера выделяется где то вначале процедуры сериализации либо 64 либо 128 байт (как я глянул в коде) потом происходит его наполнение разными данными, которые являются разными структурами, через if/else и switch/case, соответсвенно заранее спрогнозировать нужный размер буфера не возможно и получаем потенциальную возможность выхода за пределы массива.
В патче теперь добавили проверку при каждой записи в этот буфер на переполнение и соответсвенно теперь по всему коду передается не только указатель но дополнительным аргуметом размер. Это является самым удобным представлением массива по мнению сишников.
Вполне возможно стандарт синего зуба предполагает фиксированный размер пакета, но доказать то что любая комбинация тех самых if/else и switch/case выдает на выходе меньше чем N байт никто не удосужился, потому что цитата "протокол bluetooth сложный". А оказывается что ребята из armis придумали как подобрать такие параметры запроса чтобы "инвариант" нарушился.
P.S. я не специальист по ядру и тем более блютузу так что все выше изложенное сказано на правах дилетанта
Что в моем вольном переводе означает, что медиа корпорации производят кал не потому что это жидомассонский заговор, а потому что людям нравится его хавать.
А системы гугла и фейсбука с положительной обратной связью только ухудшают ситуацию.
Кроме переполнения header из комента выше могу добавит проблему что не везде есть проверки что strstr находит подстроку. И дальше может быть обращение к плохому указателю.
Из моего опыта могу сказать следующее:
Чего не хватает в си++ из коробки — это нормальных многомерных массивов.
Что мешает в фортране — это отсутствие удобного ввода вывода и то что все переменные надо объявлять в начале функции.
Чего не хватает везде — это удобной интеграции с python/numpy array, потому что отдает голый указатель а не нормальный класс.
В остальном все работает одинаково имхо.
Буду рад увидеть в обсуждении конкретные примеры и опыт использования существующих инструментов.
Картинка CopyCat наглядно показывает что в Европе 7 процентов выходцев из азии а в Америке 12.