Спасибо за интересную статью! Только вот таблицы ну очень не наглядные — что в оригинале, что у вас. Совершенно не видно того, что все они, по сути, разбиваются на три области (по кол-ву элементов). Как варианты: 1) отделить в каждой таблице жирной горизонтальной линией по три строки (с одинаковым кол-вом элементов); 2) разделить их цветом фона (первые три строки белый фон, дальше три светло-серый, потом опять три белых). Мне кажется, так результаты бенчмарков станут ещё наглядней.
Справедливости ради, KeePass (даже не задумывался над другим вариантом написания) — не библиотека, а программа для простого (не корпоративного) пользователя. И крайне маловероятно, что какая-то контора будет её закупать для своих работников (ну или, в данном случае, откажется от закупок из-за неблагозвучного имени). А уж для простого пользователя программу можно называть как угодно, и чем оригинальней, тем лучше.
Если нет, то можно хотя бы выделить страницу памяти (4096 байт), так как меньше страницы в любом случае не выделится:
v.reserve(4096);
Для reserve указывается число элементов, не байт. Кроме того, при добавлении в вектор и исчерпании capacity оно увеличивается в 1.5 раз (по крайней мере, там, где я видел реализацию, но по крайней мере всегда во сколько-то раз, а не на сколько-то). А это приводит к тому, что до 4096/sizeof(T) вектор дорастёт очень быстро, и смысла в этом reserve нет. Но, разумеется, если число элементов заранее известно, то reserve не помешает в любом случае, даже для нескольких элементов.
Да уж, «летучий» — это просто эпично. Набрать в гугле «look fly» и перейти по первой же ссылке в urban dictionary? А зачем? «И так сойдёт!» Туда же «зависания» (чуть выше правильно переведённые как «наведение мыши»).
Наша современная совместная работа с экраном, с другой стороны, является похожей на хакерскую атаку
Как совместная работа с экраном может быть похожа на хакерскую атаку? В оригинале:
Our screen sharing, on the other hand, is a bolted-on hack
Т.е., если я правильно понял, имеется в виду, что наша сегодняшняя модель совместной работы прикручена по-быстрому, лишь бы было, не так, как надо. Т.е. вместо «является похожей на хакерскую атаку» лучше написать «больше похожа на грязный и быстрый хак» (чтобы уж оставить изначальный hack).
Стал злейшим врагом главбуха. И всё потому, что у неё на юбилее сказал длинный цветистый тост, а потом ляпнул: «Вы, Марь Иванна, в свои 50 выглядите на все 100!»
Конкретно для openssl — возможно, обнуление всей выделяемой памяти и имеет смысл. Но заметьте, даже после HeartBleed так не стали делать, видимо на то были причины. Я же понял это как обнуление вообще всей памяти, во всех приложениях на C/C++, и это я всё-таки считаю оверкиллом.
Если очистка памяти относится к openssl, то, учитывая качество его кода (пришлось сталкиваться), возможно и имеет смысл. Но в общем случае, на мой взгляд, это всё-таки оверкилл.
Ну а heartbleed это не исправит. Там речь о выходе за границы массива, никакая инициализация это бы не решила. Виноват С и его свобода творить с памятью что вздумается. Суть уязвимости в том, что у нас есть короткий пакет, а внутри него указана большая длина. Отсутствие проверок длины приводит к тому, что код бездумно возвращает содержимое той длины, которое указал пакет.
Если посмотреть коммит, где heartbleed был исправлен, то там видно, что выделялся буфер бОльшего, чем нужно, размера, потом в него читался payload (то, что реально нужно было отправить назад, небольшого размера) и обратно отправлялся весь этот большой буфер. Если бы он обнулялся после выделения, то уязвимости бы не было (разве что излишнее выделение памяти и лишняя пересылка данных).
Да уж, как такое забудешь… Таскали году так в 94-м на 4-х 3-дюймовых дискетах, а потом рубились часами, а то и целый день напролёт. Ни одна другая стрелялка уже так не вставляла (хотя и в первый Quake тоже постреляли изрядно).
каждый сектор мог иметь свою индивидуальную высоту пола
Алису покусали сеошники?
Мне кажется, или ту должны быть цифры 60% и 100%? Указанные были бы, если на одни поглощённый фотон излучается три.
Для reserve указывается число элементов, не байт. Кроме того, при добавлении в вектор и исчерпании capacity оно увеличивается в 1.5 раз (по крайней мере, там, где я видел реализацию, но по крайней мере всегда во сколько-то раз, а не на сколько-то). А это приводит к тому, что до 4096/sizeof(T) вектор дорастёт очень быстро, и смысла в этом reserve нет. Но, разумеется, если число элементов заранее известно, то reserve не помешает в любом случае, даже для нескольких элементов.
Как совместная работа с экраном может быть похожа на хакерскую атаку? В оригинале:
Т.е., если я правильно понял, имеется в виду, что наша сегодняшняя модель совместной работы прикручена по-быстрому, лишь бы было, не так, как надо. Т.е. вместо «является похожей на хакерскую атаку» лучше написать «больше похожа на грязный и быстрый хак» (чтобы уж оставить изначальный hack).
В MISRA 2012 есть 3 уровня правил (обязательные, требуемые и рекомендательные). Есть ли у вас возможность включать отдельные уровни?
P.S. Кроме шуток, вместе с IDKFA были популярнейшие пароли.
Если посмотреть коммит, где heartbleed был исправлен, то там видно, что выделялся буфер бОльшего, чем нужно, размера, потом в него читался payload (то, что реально нужно было отправить назад, небольшого размера) и обратно отправлялся весь этот большой буфер. Если бы он обнулялся после выделения, то уязвимости бы не было (разве что излишнее выделение памяти и лишняя пересылка данных).
И потолка.
внутри которых