Вы рекламируете программу непонятных авторов, которую необходимо запускать с правами администратора, но для которой нельзя сделать независимый аудит. Что в ней такого, что исходники обязательно должны быть скрыты?
Да и более того, если создавать секретный чат, то желательно визуально сличить ключи, дабы не допустить MITM. Здесь пользователям либо нужно находиться непосредственно рядом друг с другом, либо придётся пересылать скриншот визуализации по альтернативному каналу. Если к этому каналу будут иметь доступ спецслужбы, в их распоряжении окажутся начальные куски SHA-1 и SHA-256 секретного ключа. При этом конечная часть этого SHA-1 скорее всего хранится на серверах Телеграма.
Так у Телеграма E2E-шифруются только секретные чаты, а обычные, многопользовательские чаты и каналы — нет. Там шифрование только канала между клиентом и сервером Телеграма, так что все такие переписки прочитать можно.
Если верить сведениям об обвинении, то Дурову предъявляют в первую очередь содействие в распространении наркотиков, детской порнографии и оружия, поскольку он не модерирует подобную переписку. Но ко всему этому у Дурова есть доступ, ведь секретный чат на расстоянии не создашь без какого-либо альтернативного канала общения.
Да, тоже не очень понял. По логике, раз это erroneous behavior, компилятор должен давать ошибку компиляции. Если же вместо этого подобный код будет молча инициализироваться какой-то фигнёй, это выглядит ещё большим вредительством.
а как они должны понять, что именно мы им прислали?
Так по логике можно начать с простейшей арифметики. Например, несколько раз передать последовательность 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. Затем несколько раз передать 2, 3, 5, 7, 11, 13, 17. Сделать это можно в виде последовательных импульсов на частоте 1420,40575 МГц (радиолиния нейтрального водорода). Достаточно развитая цивилизация вполне может иметь радиотелескопы и радиоастрономию, которая изучает Вселенную на частоте самого распространённого элемента. При этом крайне маловероятно, что такие последовательности могут быть порождены каким-либо естественным процессом, а значит, с высокой долей вероятности будут свидетельствовать о том, что их отправила некая разумная цивилизация.
Далее выше уже приведена ссылка на линкос, с помощью которого можно передать базовые научные концепции. Это как один из вариантов возможного общения. Подразумевается, что полученные сигналы могут быть постепенно расшифрованы от более простых к более сложным.
В любом случае кажется, что таким «розеттским камнем» в общении должна быть математика как наиболее формализованное, абстрактное и непротиворечивое знание о мире, которое должно совпадать у всех разумных цивилизаций в наблюдаемой Вселенной.
Или это всё действует только в отношении одиночных элементарных значений, но не массивов и не разыменованных указателей (ссылок)? Тогда какой вообще смысл?
Не получилось почему-то нагуглить это в документации для GCC, нашёл только для Arm Compiler (по сути то же самое). Получается, для элементарных значений (в том числе и указателей!) память заполняется байтами 0xAA или 0xFF, массивы заполняются значениями согласно своим элементам, структуры — поэлементно, юнионы — согласно варианту с большей длиной. В грубом приближении можно считать, что в x86-64 все неицилизированные переменные будут заполнены 0xAA. И, что самое страшное, указатели тоже.
Думаю, что такое сделано, чтобы подобные участки памяти было видно в отладчике, но всё же это выглядит довольно странно, и если программа не подвергается даже минимальному статическому анализу хотя бы на уровне компиляторовского -Wall, который покажет обращения к неициализированным переменным, то непонятно, кто тогда вообще будет её прогонять в отладчике.
В качестве схемы данных сейчас могут использовать Swagger (есть и кодогенераторы из сваггера), но он тоже не очень однозначно мапится на целевые языки.
В современных высокоуровневых / динамических языках программирования (на примере Python, JS, PHP, Perl, Ruby и т.п.), за редким исключением, все структуры данных представляют из себя комбинацию скаляров (переменных, хранящих одно значение какого-то атомарного типа данных), списков и словарей (ассоциативных массивов).
Это хорошо, но в языках со строгой статической типизацией (C++, Java, C#) структуры данных обычно представляют собой классы. И здесь появляется нюанс, что XML явно указывает типы структур в виде имён элементов, а такие форматы, как JSON и YAML — нет.
Отсюда очевидно, что неоднозначность преобразования из объектов языка программирования в «нетипизированные» форматы всё равно существует: сериализатор должен тем или иным способом сообщить тип объекта.
class Figure {}
class Rectangle extends Figure {}
class Circle extends Figure {}
class Triangle extends Figure {}
class Scene {
List<Figure> figures;
}
При десериализации автоматически был бы создан объект Scene, а также объекты фигур, которыми был бы заполнен список figures. Да, здесь есть неоднозначность, но всё выглядит достаточно просто.
В случае с JSON такая библиотека сериализации, как Jackson, может сделать подобного кадавра:
на основе, скажем, YAML — анализировать и редактировать их руками было бы В РАЗЫ (если не на порядок) легче
В отношении YAML я бы никогда не использовал слово «легче»: это крайне нетривиальный формат, не имеющий ни однозначной спецификации, ни референсной реализации, из-за чего множество имплементаций несовместимо между собой, а отдельные нюансы могут попить много крови у всех использующих такой формат:
capitals:
- country: ru
name: Moscow
- country: no
name: Oslo
многие ценят "чистый" вид и минимум прокладки проводов и троссиков
Я думал, что у профессиональных спортсменов будут немного другие критерии выбора велосипеда. Да и всё равно же прокладывать тросик задних тормозов, так в чём вообще проблема? Теоретически, по этому самому тросику можно было бы пустить управляющий сигнал.
А в чём преимущество беспроводного переключателя? Кажется, проложить тонкий провод было бы проще, дешевле, надёжнее, компактнее, да и весило бы меньше. Разве не так?
Вы рекламируете программу непонятных авторов, которую необходимо запускать с правами администратора, но для которой нельзя сделать независимый аудит. Что в ней такого, что исходники обязательно должны быть скрыты?
А что же вы сами не написали такого комментария?
И телефончики абонентов известны
Да и более того, если создавать секретный чат, то желательно визуально сличить ключи, дабы не допустить MITM. Здесь пользователям либо нужно находиться непосредственно рядом друг с другом, либо придётся пересылать скриншот визуализации по альтернативному каналу. Если к этому каналу будут иметь доступ спецслужбы, в их распоряжении окажутся начальные куски SHA-1 и SHA-256 секретного ключа. При этом конечная часть этого SHA-1 скорее всего хранится на серверах Телеграма.
Вы общаетесь конфиденциально в секретных чатах, сверив визуализацию ключа исключительно по надёжному альтернативному каналу?
Так у Телеграма E2E-шифруются только секретные чаты, а обычные, многопользовательские чаты и каналы — нет. Там шифрование только канала между клиентом и сервером Телеграма, так что все такие переписки прочитать можно.
Если верить сведениям об обвинении, то Дурову предъявляют в первую очередь содействие в распространении наркотиков, детской порнографии и оружия, поскольку он не модерирует подобную переписку. Но ко всему этому у Дурова есть доступ, ведь секретный чат на расстоянии не создашь без какого-либо альтернативного канала общения.
И если он собирался в Южную Америку, то проще было бы дозаправиться в Марокко или Сенегале, а если в Северную — тоже возникают вопросы безопасности.
юниттесты тоже можно на ИИ свалить
Да, тоже не очень понял. По логике, раз это erroneous behavior, компилятор должен давать ошибку компиляции. Если же вместо этого подобный код будет молча инициализироваться какой-то фигнёй, это выглядит ещё большим вредительством.
Так по логике можно начать с простейшей арифметики. Например, несколько раз передать последовательность 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. Затем несколько раз передать 2, 3, 5, 7, 11, 13, 17. Сделать это можно в виде последовательных импульсов на частоте 1420,40575 МГц (радиолиния нейтрального водорода). Достаточно развитая цивилизация вполне может иметь радиотелескопы и радиоастрономию, которая изучает Вселенную на частоте самого распространённого элемента. При этом крайне маловероятно, что такие последовательности могут быть порождены каким-либо естественным процессом, а значит, с высокой долей вероятности будут свидетельствовать о том, что их отправила некая разумная цивилизация.
Далее выше уже приведена ссылка на линкос, с помощью которого можно передать базовые научные концепции. Это как один из вариантов возможного общения. Подразумевается, что полученные сигналы могут быть постепенно расшифрованы от более простых к более сложным.
В любом случае кажется, что таким «розеттским камнем» в общении должна быть математика как наиболее формализованное, абстрактное и непротиворечивое знание о мире, которое должно совпадать у всех разумных цивилизаций в наблюдаемой Вселенной.
В C++26 и позднее написать
[[indeterminate]], а до того передавать ключ-ftrivial-auto-var-init=uninitializedили вообще никакого не ставить.В GCC опция pattern делает цикл на весь массив: https://godbolt.org/z/YY41Mr13d, Clang делает то же самое через memset: https://godbolt.org/z/4odYqWfo5
Не получилось почему-то нагуглить это в документации для GCC, нашёл только для Arm Compiler (по сути то же самое). Получается, для элементарных значений (в том числе и указателей!) память заполняется байтами 0xAA или 0xFF, массивы заполняются значениями согласно своим элементам, структуры — поэлементно, юнионы — согласно варианту с большей длиной. В грубом приближении можно считать, что в x86-64 все неицилизированные переменные будут заполнены 0xAA. И, что самое страшное, указатели тоже.
Думаю, что такое сделано, чтобы подобные участки памяти было видно в отладчике, но всё же это выглядит довольно странно, и если программа не подвергается даже минимальному статическому анализу хотя бы на уровне компиляторовского
-Wall, который покажет обращения к неициализированным переменным, то непонятно, кто тогда вообще будет её прогонять в отладчике.Если вдруг будет два стандарта схемы — всё равно придётся аргументировать выбор.
В чём по-вашему принципиальная разница в требованиях? Кажется, что документирование внешних API не отменяет описание структур данных.
В качестве схемы данных сейчас могут использовать Swagger (есть и кодогенераторы из сваггера), но он тоже не очень однозначно мапится на целевые языки.
Это хорошо, но в языках со строгой статической типизацией (C++, Java, C#) структуры данных обычно представляют собой классы. И здесь появляется нюанс, что XML явно указывает типы структур в виде имён элементов, а такие форматы, как JSON и YAML — нет.
Отсюда очевидно, что неоднозначность преобразования из объектов языка программирования в «нетипизированные» форматы всё равно существует: сериализатор должен тем или иным способом сообщить тип объекта.
В XML это могло бы быть сериализовано как-то так:
При десериализации автоматически был бы создан объект Scene, а также объекты фигур, которыми был бы заполнен список figures. Да, здесь есть неоднозначность, но всё выглядит достаточно просто.
В случае с JSON такая библиотека сериализации, как Jackson, может сделать подобного кадавра:
За такой код вас побьют любые адепты динамических языков. Поэтому есть вариант проще, но он тоже не универсальный:
В отношении YAML я бы никогда не использовал слово «легче»: это крайне нетривиальный формат, не имеющий ни однозначной спецификации, ни референсной реализации, из-за чего множество имплементаций несовместимо между собой, а отдельные нюансы могут попить много крови у всех использующих такой формат:
Скриптовые языки — это подмножество языков программирования, поэтому язык awk также является языком программирования.
По этой логике выходит, что в Нидерландах должны использовать Телеграм
Я думал, что у профессиональных спортсменов будут немного другие критерии выбора велосипеда. Да и всё равно же прокладывать тросик задних тормозов, так в чём вообще проблема? Теоретически, по этому самому тросику можно было бы пустить управляющий сигнал.
А в чём преимущество беспроводного переключателя? Кажется, проложить тонкий провод было бы проще, дешевле, надёжнее, компактнее, да и весило бы меньше. Разве не так?
Первый?