LINUX.ORG.RU

Избранные сообщения dataman

Показ количества неподтверждённых сообщений

 ,

Примерно так:

Все (10) Новости (1) Галерея (3) Голосования (5) Статьи (1)

dataman
()

git replay

 , , ,

В git 2.44 добавлена экспериментальная команда git replay:

git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos too


SYNOPSIS
--------
(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch>) <revision-range>...

DESCRIPTION
-----------

Takes ranges of commits and replays them onto a new location. Leaves
the working tree and the index untouched, and updates no references.
The output of this command is meant to be used as input to
`git update-ref --stdin`, which would update the relevant branches
(see the OUTPUT section below).

THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

OPTIONS
-------

--onto <newbase>
    Starting point at which to create the new commits.  May be any
    valid commit, and not just an existing branch name.

When `--onto` is specified, the update-ref command(s) in the output will
update the branch(es) in the revision range to point at the new
commits, similar to the way how `git rebase --update-refs` updates
multiple branches in the affected range.

--advance <branch>
    Starting point at which to create the new commits; must be a
    branch name.

When `--advance` is specified, the update-ref command(s) in the output
will update the branch passed as an argument to `--advance` to point at
the new commits (in other words, this mimics a cherry-pick operation).

<revision-range>
    Range of commits to replay. More than one <revision-range> can
    be passed, but in `--advance <branch>` mode, they should have
    a single tip, so that it's clear where <branch> should point
    to. See "Specifying Ranges" in git-rev-parse and the
    "Commit Limiting" options below.

OUTPUT
------

When there are no conflicts, the output of this command is usable as
input to `git update-ref --stdin`.  It is of the form:

    update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
    update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
    update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}

where the number of refs updated depends on the arguments passed and
the shape of the history being replayed.  When using `--advance`, the
number of refs updated is always one, but for `--onto`, it can be one
or more (rebasing multiple branches simultaneously is supported).
dataman
()

Rawhide — утилита поиска файлов с Си-подобным синтаксисом выражений

 , , , ,

https://github.com/raforg/rawhide

Rawhide (rh) lets you search for files on the command line using expressions and user-defined functions in a mini-language inspired by C. It’s like find(1), but more fun to use. Search criteria can be very readable and self-explanatory and/or very concise and typeable, and you can create your own lexicon of search terms. The output can include lots of detail, like ls(1).

Rawhide (rh) searches the filesystem, starting at each given path, for files that make the given search criteria expression true. If no search paths are given, the current working directory is searched.
The search criteria expression can come from the command line (with the -e option), from a file (with the -f option), or from standard input (stdin) (with -f-). If there is no explicit -e option expression, rh looks for an implicit expression among any remaining command line arguments. If no expression is specified, the default search criteria is the expression 1, which matches all filesystem entries.
An rh expression is a C-like expression that can call user-defined functions.
These expressions can contain all of C’s conditional, logical, relational, equality, arithmetic, and bit operators.
dataman
()

Flux — C++20 библиотека алгоритмов с другой моделью итераций

 , ,

Это header-only (~405 KB) C++20 библиотека в духе C++20 Ranges, Python IterTools, итераторов Rust и других, и предоставляет набор функций, в целом эквивалентный C++20 Ranges, но использует немного другую модель итерации, основанную на курсорах, а не итераторах.
Курсоры Flux - это обобщение индексов массивов, в то время как итераторы STL - обобщение указателей массивов.
Возможности:

  • большой выбор алгоритмов и адаптеров последовательностей для создания мощных (?) и эффективных конвейеров данных;
  • более высокая безопасность по сравнению со стандартными итераторами;
  • более простое использование в распространённых случаях, особенно при определении собственных последовательностей и адаптеров;
  • более эффективное выполнение некоторых распространённых операций;
  • совместимость с существующими стандартными библиотечными типами и концептами.

Документация: https://tristanbrindle.com/flux/index.html
Код: https://github.com/tcbrindle/flux
Лицензия: Boost 1.0.
Пример:

constexpr auto result = flux::ints()                        // 0,1,2,3,...
                         .filter(flux::pred::even)          // 0,2,4,6,...
                         .map([](int i) { return i * 2; })  // 0,4,8,12,...
                         .take(3)                           // 0,4,8
                         .sum();                            // 12

static_assert(result == 12);

Он же в Compiler Explorer: https://flux.godbolt.org/z/KKcEbYnTx.


Проект от автора библиотеки NanoRange – C++20 Ranges для C++17.

dataman
()

lug — DSL с расширенным PEG для C++17

 , , , ,

После 6.5 лет забвения автор выпустил версию 0.2.0 header-only библиотеки lug.

using namespace lug::language;
		rule JSON;
		rule ExponentPart   = lexeme[ "[Ee]"_rx > ~"[+-]"_rx > +"[0-9]"_rx ];
		rule FractionalPart = lexeme[ "."_sx > +"[0-9]"_rx ];
		rule IntegralPart   = lexeme[ "0"_sx | "[1-9]"_rx > *"[0-9]"_rx ];
		rule Number         = lexeme[ ~"-"_sx > IntegralPart > ~FractionalPart > ~ExponentPart ];
		rule Boolean        = lexeme[ "true"_sx | "false" ];
		rule Null           = lexeme[ "null" ];
		rule UnicodeEscape  = lexeme[ 'u' > "[0-9A-Fa-f][0-9A-Fa-f][0-9A-Fa-f][0-9A-Fa-f]"_rx ];
		rule Escape         = lexeme[ "\\" > ("[/\\bfnrt]"_rx | UnicodeEscape) ];
		rule String         = lexeme[ "\"" > *("[^\"\\\u0000-\u001F]"_rx | Escape) > "\"" ];
		rule Array          = "[" > JSON > *("," > JSON) > "]";
		rule Object         = "{" > String > ":" > JSON > *("," > String > ":" > JSON) > "}";
		JSON                = Object | Array | String | Number | Boolean | Null;
		grammar_ = start(JSON);

https://github.com/jwtowner/lug

dataman
()

μt — C++20 библиотека модульного тестирования

 , , , ,

μt¹ – небольшая (~100 Кб), header-only (единственный файл ut.hpp) C++20 библиотека модульного тестирования.
В отличие от большинства аналогов (сatch³, doctest⁴, etc.) основана не на макросах, а на возможностях стандарта C++20.
Библиотекой поддерживаются техники TDD (wikipedia.org) (разработка через тестирование), BDD (wikipedia.org) (разработка через поведение) и язык BDD Gherkin.
Зависит только от std.

Примеры:

#include <boost/ut.hpp> // import boost.ut;

constexpr auto sum(auto... values) { return (values + ...); }

int main() {
  using namespace boost::ut;

  "sum"_test = [] {
    expect(sum(0) == 0_i);
    expect(sum(1, 2) == 3_i);
    expect(sum(1, 2) > 0_i and 41_i == sum(40, 2));
  };
}
#include <boost/ut.hpp>
#include <chrono>
#include <iostream>
#include <string>
#include <string_view>

namespace benchmark {
struct benchmark : boost::ut::detail::test {
  explicit benchmark(std::string_view _name)
      : boost::ut::detail::test{"benchmark", _name} {}

  template <class Test>
  auto operator=(Test _test) {
    static_cast<boost::ut::detail::test&>(*this) = [&_test, this] {
      const auto start = std::chrono::high_resolution_clock::now();
      _test();
      const auto stop = std::chrono::high_resolution_clock::now();
      const auto ns =
          std::chrono::duration_cast<std::chrono::nanoseconds>(stop - start);
      std::clog << "[" << name << "] " << ns.count() << " ns\n";
    };
  }
};

[[nodiscard]] auto operator""_benchmark(const char* _name,
                                        decltype(sizeof("")) size) {
  return ::benchmark::benchmark{{_name, size}};
}

#if defined(__GNUC__) or defined(__clang__)
template <class T>
void do_not_optimize(T&& t) {
  asm volatile("" ::"m"(t) : "memory");
}
#else
#pragma optimize("", off)
template <class T>
void do_not_optimize(T&& t) {
  reinterpret_cast<char volatile&>(t) =
      reinterpret_cast<char const volatile&>(t);
}
#pragma optimize("", on)
#endif
}  // namespace benchmark

int main() {
  using namespace boost::ut;
  using namespace benchmark;

  "string creation"_benchmark = [] {
    std::string created_string{"hello"};
    do_not_optimize(created_string);
  };
}

BDD:

#include <boost/ut.hpp>

int main() {
  using namespace boost::ut::literals;
  using namespace boost::ut::operators::terse;
  using namespace boost::ut::bdd;

  "Scenario"_test = [] {
    given("I have...") = [] {
      when("I run...") = [] {
        then("I should have...") = [] { 1_u == 1u; };
        then("I should have...") = [] { 1u == 1_u; };
      };
    };
  };

  feature("Calculator") = [] {
    scenario("Addition") = [] {
      given("I have number 40") = [] {
        auto number = 40;
        when("I add 2 to number") = [&number] { number += 2; };
        then("I expect number to be 42") = [&number] { 42_i == number; };
      };
    };
  };

  // clang-format off
  scenario("Addition");
    given("I have number 40");
      auto number = 40;

    when("I add 2 to number");
      number += 2;

    then("I expect number to be 42");
      42_i == number;
}

Gherkin:

#include <boost/ut.hpp>
#include <fstream>
#include <numeric>
#include <streambuf>
#include <string>

template <class T>
class calculator {
 public:
  auto enter(const T& value) -> void { values_.push_back(value); }
  auto add() -> void {
    result_ = std::accumulate(std::cbegin(values_), std::cend(values_), T{});
  }
  auto sub() -> void {
    result_ = std::accumulate(std::cbegin(values_) + 1, std::cend(values_),
                              values_.front(), std::minus{});
  }
  auto get() const -> T { return result_; }

 private:
  std::vector<T> values_{};
  T result_{};
};

int main(int argc, const char** argv) {
  using namespace boost::ut;

  bdd::gherkin::steps steps = [](auto& steps) {
    steps.feature("Calculator") = [&] {
      steps.scenario("*") = [&] {
        steps.given("I have calculator") = [&] {
          calculator<int> calc{};
          steps.when("I enter {value}") = [&](int value) { calc.enter(value); };
          steps.when("I press add") = [&] { calc.add(); };
          steps.when("I press sub") = [&] { calc.sub(); };
          steps.then("I expect {value}") = [&](int result) {
            expect(that % calc.get() == result);
          };
        };
      };
    };
  };

  // clang-format off
  "Calculator"_test = steps |
    R"(
      Feature: Calculator

        Scenario: Addition
          Given I have calculator
           When I enter 40
           When I enter 2
           When I press add
           Then I expect 42

        Scenario: Subtraction
          Given I have calculator
           When I enter 4
           When I enter 2
           When I press sub
           Then I expect 2
    )";
  // clang-format on

  if (argc == 2) {
    const auto file = [](const auto path) {
      std::ifstream file{path};
      return std::string{(std::istreambuf_iterator<char>(file)),
                         std::istreambuf_iterator<char>()};
    };

    "Calculator"_test = steps | file(argv[1]);
  }
}

  1. https://github.com/boost-ext/ut
  2. https://boost-ext.github.io/ut – примеры, документация, бенчмарки
  3. https://github.com/catchorg/Catch2
  4. https://github.com/doctest/doctest
  5. https://boost-ext.github.io/ut/denver-cpp-2019 – слайд-презентация.
  6. https://www.youtube.com/watch?v=irdgFyxOs_Y – презентация на CppCon 2020.
dataman
()

Уменьшить минимальный размер изображений

 , , ,

Часто какое-нибудь лого программы или библиотеки имеет размер меньше, чем 400x400. Ещё чаще оно не квадратное.
Хотелось бы уменьшить до 200.

dataman
()

Сколько нужно памяти для компиляции bmake?

 , , ,

Пытаюсь скомпилировать (GCC 14.1) bmake (исходники). Свободных 6Gb не хватает, система намертво виснет.
Есть желающие попытаться? :)

dataman
()

Обновление подсветки синтаксиса

 , ,

В движке сайта – большое обновление подсветки синтаксиса. Добавлены:

ARMASM
AVRASM
AWK
Basic
Brainfuck
C
JSON
Julia
Lisp
LLVM
Makefile
MIPSASM
Nim
Nix
Ocaml
Scheme
TCL
TypeScript
Vim
WASM
X86ASM
YAML

Подробности

Перемещено hobbit из linux-org-ru

dataman
()

Телеметрии в LLVM быть?!

 , , ,

dataman
()

Спойлеры в сообщениях

 , ,

Хотя бы в ОП. Особенно будет полезно в объёмных статьях.
Например, Приложения и утилиты, которые стоит попробовать тяжело читать.

Пример возможного синтаксиса:

>>> sed → sd
свёрнутый, по умолчанию, текст
<<<
dataman
()

Замена 😊 в реакциях на другой символ

 , ,

Смеющийся смайлик какой-то дурацкий!

Кандитаты:

  1. 😀
  2. 😁
  3. 😆
  4. 🙂
  5. 😄
  6. 😃
    … ?

diff --git a/src/main/scala/ru/org/linux/reaction/ReactionService.scala b/src/main/scala/ru/org/linux/reaction/ReactionService.scala
index aa6dde91e..dd31c5a99 100644
--- a/src/main/scala/ru/org/linux/reaction/ReactionService.scala
+++ b/src/main/scala/ru/org/linux/reaction/ReactionService.scala
@@ -97,7 +97,7 @@ object ReactionService {
   val DefinedReactions: Map[String, String] = Map(
     "\uD83D\uDC4D" -> "большой палец вверх",
     "\uD83D\uDC4E" -> "большой палец вниз",
-    "\uD83D\uDE0A" -> "улыбающееся лицо",
+    "\uD83D\uDE42" -> "смешно!",                  // 🙂
     "\uD83D\uDE31" -> "лицо, кричащее от страха",
     "\uD83E\uDD26" -> "facepalm",
     "\uD83D\uDD25" -> "огонь",
dataman
()

Зонд NASA Parker рекордно сблизился с Солнцем

 , , ,

Сегодня в 14:53 по московскому времени американский межпланетный зонд Parker совершил самый близкий пролёт близ Солнца. В этот момент он приблизился на 6,1 миллионов километров к нашему светилу на скорости 690 тыс. км в час.

Хотя NASA ожидает, что Parker пролетит мимо Солнца по крайней мере ещё дважды (если, конечно, зонд не будет повреждён высокой температурой), нынешний пролёт стал рекордным по близости к Солнцу.

«В канун Рождества 1969 года мы высадили людей на Луне; в канун Рождества 2024 года мы попытаемся обнять звезду», — сказал Нур Рауафи (Nour Raouafi), научный сотрудник проекта Parker Solar Probe.

На данный момент связи с зондом нет, она восстановится 27 декабря. А собранные научные данные аппарат начнёт передавать на Землю в конце января 2025 года, когда займёт наиболее благоприятствующее для связи положение на орбите. Если всё пойдёт хорошо, Parker продолжит свою миссию: он снова пролетит возле Солнца 22 марта 2025 года и 19 июня 2025 года.

Источник полностью ёфицирован.

dataman
()

В Geany добавили фильтрацию по сочетанию клавиш

 , , ,

https://github.com/geany/geany/pull/4192

Но фильтруется только по названию действия, а не по самому сочетанию. :(

dataman
()

Автор whisper.cpp ищет сопровождающих

 , , , ,

https://github.com/ggerganov/whisper.cpp/discussions/2788

В последнее время я стал уделять проекту меньше внимания, поскольку мое внимание сместилось в сторону llama.cpp и ggml. Тем не менее, whisper.cpp остается действительно классным проектом, который используется многими разработчиками и продуктами. В целом он находится в хорошем состоянии с точки зрения основной реализации и функциональности. Однако ему все больше и больше не хватает CI, документации, упаковки и распространения.

Я создал дорожную карту с некоторыми вещами, которые, по моему мнению, необходимо улучшить в будущем:

https://github.com/users/ggerganov/projects/16/

Это несколько высокоуровневых задач с множеством ответвлений и возможностей для внесения вклада. В основном они направлены на улучшение опыта разработчиков и конечных пользователей при использовании проекта. Конечная цель состоит в том, чтобы в какой-то момент у проекта появился долгосрочный сопровождающий (не я) и чтобы он продолжал жить под организацией ggml-org на Github (см. #2786).

Это обсуждение создано для того, чтобы привлечь к этому больше внимания в надежде получить некоторую поддержку со стороны сообщества. Не стесняйтесь задавать любые вопросы или предлагать идеи по улучшению проекта. Тем не менее, я не хочу погрязнуть в обсуждении и планировании – основные шаги уже есть в дорожной карте выше, и они просто требуют исполнения.

Переведено DeepL.

dataman
()

Геологическая история Марса: рентгеновский спектрометр помогает разгадывать марсианские загадки

 , perseverance, ,

Учёные раскрывают секреты формирования планеты в образцах древних вулканов Марса.

В новом исследовании международная группа учёных во главе с профессором Мариек Шмидт из Университета Брока представила открытия о критическом периоде эволюционной истории Марса. Работа раскрывает новые подробности о геологическом прошлом Красной планеты.

Профессор Шмидт, возглавляющая кафедру наук о Земле в Университете Брока, участвовала в миссии марсохода Perseverance NASA в качестве научного сотрудника. Она и её коллеги анализировали древние породы, найденные в кратере Езеро на Марсе. Одной из основных целей миссии был поиск признаков древней микробной жизни, но изучение магматических пород и реголита в этом районе также дало представление о малоизученном периоде истории планеты.

«Мы делаем на Марсе то, чего никогда раньше не делали», – говорит Шмидт. Она также является со-исследователем в команде, работающей с прибором PIXL (Planetary Instrument for X-Ray Lithochemistry). Этот рентгенофлуоресцентный спектрометр использовался для определения элементного состава марсианских поверхностных материалов с высоким разрешением, позволяя учёным дистанционно «заглянуть» вглубь пород, чтобы исследовать, как они формировались и из чего состоят.

«Масштаб научных исследований был невероятным. Это самое всестороннее на сегодняшний день изучение образцов, которые были сохранены для возвращения на Землю», – отмечает Шмидт. «Теперь мы знаем минеральный и химический состав пород, понимаем их текстуры, но следующим шагом было рассказать о том, как, по нашему мнению, формировались эти породы с точки зрения подъёма магмы через марсианскую кору, её кристаллизации, эволюции и изменения состава».

Работа также выдвигает ряд гипотез, которые могут направлять дальнейшие исследования, когда образцы будут доставлены на Землю.

Таня Кизовски, соавтор статьи и заместитель куратора по минералогии в Королевском музее Онтарио, отмечает, что все марсианские образцы, изученные на Земле до сих пор, были метеоритами. Большинство марсианских метеоритов имеют возраст менее 500 миллионов лет, что относительно молодо по сравнению с 4,5-миллиардной историей Марса. В то же время образцы из кратера Езеро, как полагают, имеют возраст не менее 3,5 миллиардов лет.

«Марс очень хорошо сохранился с точки зрения ранней истории нашей Солнечной системы, поэтому возможность изучать такие древние породы, особенно когда они будут доставлены на Землю, поможет нам узнать об истории внутренней части Солнечной системы и о том, когда возникла жизнь», – говорит Кизовски.

Образцы также происходят из уникального периода в истории Марса, когда внутренняя динамика планеты претерпевала серьёзные изменения. Шмидт объясняет: «Вулканизм на Марсе в основном связан с так называемыми горячими точками, подобными Гавайям или Исландии на Земле, где есть сфокусированный источник магмы, уходящий глубоко, пробивающийся через всё и затем извергающийся на поверхность. Но в ранней истории Марса есть модели, подтверждающие идею о том, что марсианская кора формировалась в результате широко распространённого вулканизма, не обязательно сосредоточенного в этих горячих точках, и этот переход, как считается, произошёл примерно в то время, когда формировались эти породы».

Шмидт и её команде ещё предстоит подождать – возможно, десятилетие или больше – прежде чем образцы буду доставлены на Землю. «Доставка этих образцов с Марса будет невероятно сложной задачей и потребует удивительного инженерного подвига, особенно если учесть, что вы доставляете с орбиты нечто размером с баскетбольный мяч», – говорит Шмидт.

Тем временем марсоход Perseverance продолжает исследовать новые районы Марса и собирать образцы, а Шмидт и её коллеги терпеливо ожидают возможности однажды проанализировать марсианские породы уже на Земле.

Это исследование открывает новую главу в изучении Марса, предоставляя учёным беспрецедентную возможность заглянуть в далёкое прошлое планеты. Анализ древних пород из кратера Езеро не только проливает свет на геологическую историю Марса, но и может помочь в поиске следов древней жизни на планете. Кроме того, эти данные могут быть ключом к пониманию ранних этапов формирования планет в Солнечной системе.

Источник: https://www.ixbt.com/news/2025/02/08/geologicheskaja-istorija-marsa-rentgenovskij-spektrometr-pomogaet-razgadyvat-marsianskie-zagadki.html.

https://ru.wikipedia.org/wiki/Езеро_(кратер)
https://ru.wikipedia.org/wiki/Персеверанс_(марсоход)

dataman
()

Форкнули QuickJS

 , , , ,

Оригинал Белларда: https://github.com/bellard/quickjs.
Форк: https://github.com/quickjs-ng/quickjs:

QuickJS is a small and embeddable JavaScript engine. It aims to support the latest ECMAScript specification.
This project is a fork of the original QuickJS project by Fabrice Bellard and Charlie Gordon, after it went dormant, with the intent of reigniting its development.

Версия 0.8.0 от 24 декабря 2024.


Другие JavaScript-движки на C.

https://github.com/svaarala/duktape – больше года без изменений.

Duktape is an embeddable Javascript engine, with a focus on portability and compact footprint.

https://github.com/jerryscript-project/jerryscript – версия 3.0.0 от 18 декабря 2024.

JerryScript is a lightweight JavaScript engine for resource-constrained devices such as microcontrollers. It can run on devices with less than 64 KB of RAM and less than 200 KB of flash memory.

dataman
()

Свершилось! На GitHub можно обсуждать Midnight Commander!

 , ,

https://github.com/MidnightCommander/mc-old

Midnight Commander’s Legacy Repository

⚠️ This repository has been archived! ⚠️

It reflects the state just before we switched from Trac to GitHub for issue tracking on Feb 28, 2025.

Please use the new repository at MidnightCommander/mc instead!

– Maintainers


MidnightCommander/mc

Уже:

Issues 620

https://github.com/MidnightCommander/mc/discussions/4658

Welcome to Midnight Commander Discussions!

dataman
()

Бьёрн Страуструп призвал стандартизировать профили C++ для безопасной работы с памятью

 , , ,

https://www.opennet.ru/opennews/art.shtml?num=62821

Бьёрн Страуструп (Bjarne Stroustrup), создатель языка C++, призвал комитет WG21, отвечающий за разработку стандартов для языка C++, предпринять меры для сохранения актуальности C++ в условиях активного продвижения инициатив по переходу на языки, обеспечивающие безопасную работу с памятью. Страуструп считает, что язык С++ уже содержит все возможности, необходимые для безопасной работы с памятью. Остаётся только предоставить средства, гарантирующие, что код написан с использованием только безопасных возможностей.

По мнению Страуструпа, времени осталось очень мало и необходимо до 2026 года успеть предпринять какие-то меры, так как Агентство по кибербезопасности и защите инфраструктуры США и ФБР стали более активно продвигать среди производителей ПО идею перехода на языки, безопасного работающие с памятью. До 2026 года производителям ПО рекомендовано разработать план по применению в своих продуктах технологий, защищающих от ошибок при работе с памятью, или переходу на использование языков, безопасно работающих с памятью.

Стандартизация возможностей для безопасной разработки на C++ позволит сохранить интерес к языку С++, особенно с учётом того, что разработчики существующих проектов на С и C++ смогут постепенно наращивать безопасность своих продуктов, не прибегая к инициативам по переписыванию на другом языке. В частности, проекты на C можно преобразовать в код С++, а за тем поэтапно переводить код на безопасные конструкции, следуя рекомендациям из руководства «C++ Core Guidelines».

Для обеспечения разработки безопасного кода Страуструп предлагает стандартизировать систему профилей C++, вводящих дополнительные требования к коду. Профили близки к применению флагов -Wall и -Wextra при компиляции, но в отличие от них работают на уровне запрета применения определённых возможностей языка. К реализации предлагаются профили для безопасных типов, контроля времени жизни объектов, работы с допустимыми диапазонами значений и целочисленной арифметики. Привязку к профилям можно задавать не только для проекта и файлов (например, [[profile::enforce(type)]]), но и включать/отключать на уровне отдельных конструкций (например, [profile::suppress(lifetime))] this->succ = this->succ->succ;).

Работа по повышению безопасности будет сводится к включению профиля для определённого кода и переписыванию частей, использующих небезопасные возможности языка, охватываемые выбранным профилем. Например, использование профилей поможет уйти от применения в коде сырых указателей и массивов, избавиться приведения типов и защититься от обращений к неинициализированным объектам. Вместо сырых указателей можно использовать, например, умные указатели std::unique_ptr и std::shared_ptr с отслеживанием владения. При наличии в коде циклов «for», перебирающих отдельные элементы Си-массива, потребует заменить данные циклы на вариант с обработкой диапазонов for(type variable : vector), использующий std::vector.

Предложены следующие профили:

  • type – каждый объект должен быть инициализирован, не допускается приведение типов.
  • lifetime – запрещены ссылки на освобождённые или неиспользуемые области памяти, разыменование указателей, явный вызов new/delete.
  • bounds – требуется проверка допустимых диапазонов при работе с указателями, запрещены арифметические операции с указателями.
  • arithmetic – блокируются целочисленные переполнения, запрещены знаковые/беззнаковые преобразования, изменяющие значение.
  • concurrency – исключает операции, приводящие к взаимным блокировкам и состояниям гонки.
  • RAII (Resource Acquisition Is Initialization) – требует проверки владения для каждого ресурса.

Гарантии, реализуемые при использовании профилей:

  • Обращение к объекту допускается только в соответствии с типом, под которым этот объект был определён.
  • Каждый объект должен быть корректно создан и освобождён.Каждый объект должен быть корректно создан и освобождён.
  • Каждый указатель должен указывать на корректный объект или нулевой указатель.
  • Каждая ссылка через указатель не должна переходить по нулевому указателю.
  • Каждое обращение через индексированный указатель должно находиться в пределах допустимого диапазона.
dataman
()

Растогруб

 ,

https://www.opennet.ru/opennews/art.shtml?num=62945

Разработчики GRUB2 рассматривают возможность использования языка Rust.

Владимир Сербиненко, один из трёх мэйнтейнеров загрузчика GRUB2, внёсший в кодовую базу более пяти тысяч изменений, выставил на обсуждение возможность написания модулей для GRUB2 c использованием языка Rust. Владимир представил первые результаты экспериментов с добавлением поддержки Rust в GRUB2 и созданием необходимых обвязок. Для GRUB также подготовлены изменения, позволяющие использовать разделяемые библиотеки («.so», ET_DYN) для модулей, вместо связывания на уровне объектных файлов («.o», ET_REL).

Инициатива пока позиционируется как отдельный эксперимент, который не будет влиять на разработку GRUB2. В качестве оптимального применения Rust в GRUB упоминается написание модулей для новых файловых систем. Также не исключается переписывание на Rust кода для работы с дисковыми разделами и GPT.

Предполагается, что использование Rust поможет проекту уменьшить вероятность появление некоторых видов ошибок, особенно в коде модулей, содержащем множество больших и сложных процедур парсинга. В феврале в результате аудита кодовой базы GRUB были выявлены 72 проблемы с безопасностью, 21 из которых признаны опасными уязвимостями, пригодными для обхода механизма верифицированной загрузки UEFI Secure Boot. 20 из 21 уязвимостей вызваны ошибками при работе с памятью, приводившими к переполнению буфера или обращению к памяти после её освобождения.

Дополнительно можно отметить выпуск проекта GNU Boot 0.1 RC6, в состав которого вошли вышеотмеченные исправления уязвимостей (в самом GRUB2 исправления продолжают распространяться в виде патчей без формирования отдельного релиза). Проект GNU Boot развивает замену проприетарным прошивкам UEFI и BIOS, основанную на CoreBoot, но применяющую более жёсткие требования к включению бинарных компонентов. GNU Boot преподносится как «coreboot-libre», т.е. как редакция CoreBoot, избавленная от блобов и несвободных компонентов, по аналогии с тем, как проект Linux-libre развивает очищенный вариант ядра Linux. Отдельно развиваются похожие проекты Libreboot и Canoeboot.

dataman
()