нашел наконец, они тут повысили планку с миллионов строк кода на Си/C++ в мире до триллионов, но суть та же: железо намного легче заменить, чем язык. Достаточно в новые процессоры Intel и AMD добавить начиная с 2030 к примеру, и через 20 лет большинство компьютеров сами пользователи себе обновят (чтобы поиграть в игры 2050 года и т.д.), по самым типичным причинам, без огромных вложений

Реализация на уровне архитектуры:
https://www.youtube.com/watch?v=5F1_3eeEsU4

Порт Linux:
https://www.youtube.com/watch?v=aLc92JHfokY

Порт V8:
https://www.youtube.com/watch?v=3XBSny5Yc58

Прямо сейчас, по меркам безопасности в релизных сборках можно расставить языки Rust -> Zig -> C/C++. В случае Rust к примеру, FFI небезопасен, и какая-нибудь программа может вызвать функцию из библиотеки на C или Zig, которая ломает всю безопасность системы спокойно. Ну или в unsafe делают transmute рандомный какой нибудь.

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

Будет обидно, если Rust и C/C++ будут работать спокойно дополнять друг друга изолированно и безопасно, а Zig станется самым небезопасным/непортируемым.

Пока есть время исправить ошибку с единственным типом usize и внедрить улучшения в сам язык перед 1.0, думаю стоит воспользоваться.

К примеру на Си у них есть хедер с такими функциями:
cheri_address_get, cheri_base_get, cheri_address_set и т.д.

На Zig это можно было бы представить так же, как поля для срезов ptr и len, только для указателей:

var ptr: [*]u32 = ...;
ptr.address += 1;
ptr.permissions = .read_only;

Другой вариант: в Си есть паттерн с containerof, где из указателя к полю структуры получают указатель ко всей структуре.

В обычных CHERI C компиляторах указатель на поле структуры автоматом получит более точный и меньший диапазон, чем указатель к структуре. Так как указатели невозможно "расширить" обратно, такой прикол не сработает. Для этих случаев есть аттрибуты, которые контролируют это ограничение (no subobject bounds)

В Zig для этого есть одна встроенная функция @fieldParentPtr. Компилятор Zig может просто проверять, используется ли она в каком-то месте для какой-то структуры. Если нет, включаем сжатие границ для них, если есть, отключаем.

а да, и ещё addrspace(.generic) придётся переделать или удалить, но вроде как AVR и SPIR-V мейнтейнеры и так хотят убрать его

потому что в гибрид моде у обычных указателей будет addrspace 0 (как обычно на x86-64), а у capabilities 200, чтобы старый код мог работать дальше на CHERI системах (например, закрытые программы или библиотеки, которые нельзя пересобрать), и рантайм мог отличать его от нового

в обоих случаях проверки будут работать, потому что старый код с указателями в рантайме просто прячет за собой capability, и те же проверки на границы и т.д., просто их не модифицируют вручную (не сжимают границы функциями по типу cheri_bounds_set т.д., потому что их нет в старом коде)

[RFC] Libc++ taking a dependency on Boost.Math for the C++17 Math Special Functions

У libc++ (стандартной библиотеки C++ от LLVM) может появиться новая зависимость Boost.Math, которая позволит докончить поддержку C++17 в коде.

Почти все соглашаются и поддержиают это решению, но Эндрю говорит это помешает сильно для zig и zig c++:

This is apocalyptic for us. We, and our users would strongly prefer missing C++17 features than a Boost.Math dependency.

If LLVM moves forward with this, we will very likely patch it out.

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

https://codeberg.org/breadtom/expozig

Альтернативный компилятор для Zig на Си. Автор хочет другой способ бутстрапинга сделать, без WASM файлов, от Си сразу к Zig

https://github.com/akhildevelops/cudaz

Библиоткеа для работы с CUDA

#библиотеки

https://github.com/ziglang/zig/pull/24699

Эндр подчищает ring buffers в стандартной библиотеке (их в сумме 4, один он убирает в другом ПР и один тут).

BoundedArray он так и не полюбил :( опять хочет его удалить.

#upstream

10 лет с момента создания Zig:

https://github.com/ziglang/zig/commit/8e08cf4bec80b87a7a22a18086a3db5c2c0f1772

Старый Hello World 2015 года:

export executable "hello";

#link("c")
extern {
    fn printf(__format: *const u8, ...) -> i32;
    fn exit(__status: i32) -> unreachable;
}

export fn _start() -> unreachable {
    printf("Hello, world!\n");
    exit(0);
}

Влияние Rust здесь хорошо видно.

0.1.0 (октябрь 2017):

const io = @import("std").io;

pub fn main() -> %void {
    %return io.stdout.printf("Hello, world!\n");
}

0.2.0 (март 2018):

const std = @import("std");

pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write("Hello, world!\n");
}

По сути этот синтаксис до сих пор остался. (и наверно работал бы на 0.14, если бы не ошибки-варнинги по типу variable is not mutable)

Про I/O и Writergate:

Don't Forget To Flush by Andrew Kelley

Осторожно, в начале громкий звук

Seems good for now but note this is going to disrupt my ultimate plan of creating a viable binary including when there are compilation errors. Including when there are syntax errors.

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

На моей памяти это первый раз, когда он упоминает этот план публично, я его ни в каких issues, PR и т.д. не видел раньше

https://github.com/ziglang/zig/pull/24857#issuecomment-3192324792

#upstream