FFI и взаимодействие с C — бесплатный тест онлайн

Вопрос 1 из 30

Какой узкий вывод следует из проверки `std::mem::forget`?

let mut v = vec![1u8, 2, 3];
let buf = Buffer { ptr: v.as_mut_ptr(), len: v.len(), cap: v.capacity() };
std::mem::forget(v);
// позже ровно один Vec::from_raw_parts(buf.ptr, buf.len, buf.cap)

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Если основной путь стабилен, ранний выход и повторный вход можно не воспроизводить отдельно. Раз тест прошёл, производительность решения тоже можно считать подтверждённой. forget передаёт ответственность за освобождение наружу; без гарантированного обратного вызова возникнет утечка, а двойное восстановление даст double free. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 2 из 30

Какой дефект способен воспроизвести тест `size_of`?

assert_eq!(std::mem::size_of::<Point>(), 8);
assert_eq!(std::mem::align_of::<Point>(), 4);

Для структуры из двух соседних i32 проверка сопоставляет layout с массивом из тех же элементов и не зашивает в тест числовые размеры конкретной архитектуры. Совпадающее объявление на стороне C всё равно обязательно. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Соседние ветви ошибки, отмены и частичного выполнения тогда считают проверенными автоматически. Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Успешная ветвь служит достаточным доказательством поведения при ошибке и повторном выполнении. Тогда различия между обычным и граничным случаем для `std::mem` исчезли бы. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный тест другого состояния при таком толковании уже не требуется.

Вопрос 3 из 30

Какое утверждение о «Владение на границе» остаётся верным при смене входных данных?

Владение не кодируется сырым указателем автоматически; FFI API обязан явно определить создание, передачу, заимствование и уничтожение каждого ресурса. Repr(C) гарантирует одинаковый layout для String, Vec и всех Rust enum на стороне C. Контракт «Владение на границе» считался бы одинаковым при любом состоянии входа. Set_len одновременно выделяет capacity и инициализирует новые элементы. По этой логике отдельная проверка «Владение на границе» на другом входе считалась бы лишней. Успешная линковка подтверждает правильность внешней сигнатуры и соглашения вызова. Следовательно, поведение `#[repr(C)]` считалось бы одинаковым для всех допустимых типов. Repr(C) делает любой Rust-тип пригодным для передачи в C без дополнительного контракта. Следовательно, поведение `#[repr(C)]` считалось бы одинаковым для всех допустимых типов.

Вопрос 4 из 30

Где заканчивается гарантия обычного сценария для «Владение на границе»?

Один Miri-тест покрывает все значения индекса и длины, потому что интерпретатор знает инварианты типа. Repr(C) делает внутренний layout вечным semver-контрактом даже без публичного обещания. Поэтому ошибочный сценарий вокруг «Владение на границе» не проверяли бы отдельно. Если C-функция нашлась при линковке, различие allocator и правил освобождения исключено. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Такое рассуждение переносило бы вывод о «Владение на границе» на неисполненную ветвь. Паника не может возникнуть между передачей владения и установкой guard, если код находится в `unsafe`-блоке. Восстановление Vec::from_raw_parts допустимо только с исходными ptr, len и cap от совместимого Vec и ровно один раз; изменение capacity на стороне C разрушает контракт.

Вопрос 5 из 30

Какая правка выдержит ревью контракта «Соглашение вызова ABI»?

extern "C" fn add(a: i32, b: i32) -> i32 { a + b }
let f: extern "C" fn(i32, i32) -> i32 = add;
println!("{}", f(2, 3));

Расширить `unsafe`-блок вокруг `extern` до всей функции, оставив инварианты данные этого фрагмента неоформленными. Проверка инварианта при этом переходит из системы типов в ручную обязанность автора кода. Указывать ABI явно на границе и не приводить function pointer между несовместимыми сигнатурами; panics не должны пересекать ABI без поддерживаемого unwind-контракта. Использовать `transmute` для данных рядом с `extern`, не проверяя размер, выравнивание и допустимые значения. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Подавить сообщение Miri или санитайзера для `extern`, если обычный тест не воспроизводит сбой. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Считать layout вокруг `extern` на текущей цели стабильным ABI-контрактом и удалить явные проверки границы «Соглашение вызова ABI».

Вопрос 6 из 30

Какая правка выдержит ревью контракта «Безопасность и производительность»?

extern "C" fn callback(data: *const u8, len: usize) {
    let bytes = unsafe { std::slice::from_raw_parts(data, len) };
    process(bytes);
}

Расширить `unsafe`-блок вокруг `extern` до всей функции, оставив инварианты данные этого фрагмента неоформленными. Считать layout вокруг `extern` на текущей цели стабильным ABI-контрактом и удалить явные проверки границы «Безопасность и производительность». Использовать `transmute` для данных рядом с `extern`, не проверяя размер, выравнивание и допустимые значения. Проверить договорённость о null для пустого буфера, использовать NonNull::dangling для zero-length на своей стороне и не сохранять срез после callback. Проверить только ptr!= null; выравнивание, длину, инициализацию и aliasing считать следствием ненулевого адреса.

Вопрос 7 из 30

Где заканчивается гарантия обычного сценария для «Соглашение вызова ABI»?

После проверки обычного входа можно не рассматривать panic во время частичной инициализации. Repr(C) делает внутренний layout вечным semver-контрактом даже без публичного обещания. Тогда поведение «Соглашение вызова ABI» при раннем выходе выводили бы из обычного пути. Паника не может возникнуть между передачей владения и установкой guard, если код находится в `unsafe`-блоке. Такое рассуждение переносило бы вывод о «Соглашение вызова ABI» на неисполненную ветвь. Если C-функция нашлась при линковке, различие allocator и правил освобождения исключено. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. По этой логике отдельная проверка «Соглашение вызова ABI» на другом входе считалась бы лишней. Паника через ABI, который не разрешает unwinding, может привести к аварийному завершению; callback должен перехватить panic до возврата в C.

Вопрос 8 из 30

Какое утверждение о механизме «Внешние функции extern» можно переносить на другие примеры?

Успешная линковка доказывает совпадение ABI и сигнатур. Контракт «Внешние функции extern» считался бы одинаковым при любом состоянии входа. Успешная линковка подтверждает правильность внешней сигнатуры и соглашения вызова. Следовательно, поведение `std::ffi::c_char` считалось бы одинаковым для всех допустимых типов. extern-блок объявляет внешние символы и ABI; вызов unsafe-функции требует соблюсти контракт другой стороны, включая типы и владение. При len=0 любой указатель, включая null и невыравненный, допустим для создания Rust-среза. Такое рассуждение переносило бы вывод о «Внешние функции extern» на неисполненную ветвь. Miri доказывает отсутствие UB во всех путях программы, даже не выполненных тестами. Следовательно, поведение `std::ffi::c_char` считалось бы одинаковым для всех допустимых типов.

Вопрос 9 из 30

Что произойдёт после операции `extern "C"`?

extern "C" fn callback(data: *const u8, len: usize) {
    let bytes = unsafe { std::slice::from_raw_parts(data, len) };
    process(bytes);
}

Проверка типов завершится ошибкой: `extern`-блок редакции 2024 помечен unsafe. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Код компилируется, но miri автоматически исправляет нарушение aliasing и продолжает тест. Значит, выполнение должно пройти через `std::slice::from_raw_parts` без изменения сигнатуры. Сборка остановится: в safe-оболочке проверяется индекс. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Сборка пройдёт, поскольку `unsafe`-блок проверяет валидность указателя перед разыменованием. Значит, выполнение должно пройти через `std::slice::from_raw_parts` без изменения сигнатуры. Safe-код process защищён только если C гарантирует ненулевой корректно выровненный указатель для len байтов на всё время вызова; from_raw_parts имеет строгие предусловия даже при len 0.

Вопрос 10 из 30

Что устанавливает сценарий `extern "C"` и где проходит граница его вывода?

extern "C" fn callback(data: *const u8, len: usize) {
    let bytes = unsafe { std::slice::from_raw_parts(data, len) };
    process(bytes);
}

# Инцидент: C передал data = NULL, len = 0; from_raw_parts всё равно требует non-null aligned pointer.

Причина — неверно заданный zero-length контракт; safe-оболочка должна отдельно обработать пустой ввод, не создавая срез из null. Проверка подтверждает производительность решения, даже если в ней нет измерения времени, памяти или аллокаций; результат проверки с `extern` предлагается переносить на все остальные ветви. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Дополнительный сценарий вокруг `std::slice::from_raw_parts` при таком толковании уже не требуется. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный сценарий вокруг `std::slice::from_raw_parts` при таком толковании уже не требуется. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы. Дополнительный сценарий вокруг `std::slice::from_raw_parts` при таком толковании уже не требуется.

Вопрос 11 из 30

Что показывает `c_string_rejects_inner_nul` применительно к механизму «Тестирование и инструменты Cargo»?

#[test]
fn c_string_rejects_inner_nul() {
    assert!(std::ffi::CString::new(b"a\0b".to_vec()).is_err());
}

Тест фиксирует важное предусловие C-строки: внутренний NUL недопустим и не должен тихо обрезать данные. Такая запись допустима, так как miri подтверждает отсутствие UB во всех неисполненных ветвях. Проверка типов пропустит этот путь: `unsafe`-блок проверяет валидность указателя перед разыменованием. Код компилируется, но miri автоматически исправляет нарушение aliasing и продолжает тест. Код компилируется, но несовпадение ABI проявляется только кодом ошибки внешней функции.

Вопрос 12 из 30

Какое правило связывает типы и наблюдаемое поведение в механизме «Представление типов»?

Miri доказывает отсутствие UB во всех путях программы, даже не выполненных тестами. Контракт «Представление типов» считался бы одинаковым при любом состоянии входа. Обычный repr(Rust) не обещает стабильный порядок и layout полей; repr(C) нужен для бинарной границы, но не сериализует данные автоматически. Unsafe отключает borrow checker и остальные проверки типов внутри блока. Repr(C) делает любой Rust-тип пригодным для передачи в C без дополнительного контракта. Тогда различия между обычным и граничным случаем для «Представление типов» исчезли бы. Repr(C) гарантирует одинаковый layout для String, Vec и всех Rust enum на стороне C. Следовательно, поведение `#[repr(C)]` считалось бы одинаковым для всех допустимых типов.

Вопрос 13 из 30

Как проявится механизм «Соглашение вызова ABI» при выполнении кода?

extern "C" fn add(a: i32, b: i32) -> i32 { a + b }
let f: extern "C" fn(i32, i32) -> i32 = add;
println!("{}", f(2, 3));

Код компилируется, но невалидный указатель всегда вызывает контролируемую panic до чтения памяти. Тогда поведение `add` при раннем выходе выводили бы из обычного пути. До запуска дело не дойдёт: `extern`-блок редакции 2024 помечен unsafe. Этот фрагмент будет отклонён: структура на FFI-границе имеет repr(C). До выполнения код дойдёт без ошибки компиляции, поскольку repr(C) делает любой Rust-тип пригодным для передачи в C без дополнительного контракта. Код печатает 5: тип function pointer включает C ABI и совместим с объявленной функцией.

Вопрос 14 из 30

Что исправить вокруг `#[repr(C)]`, чтобы граничный вход обрабатывался безопасно?

#[repr(C)]
struct Point { x: i32, y: i32 }

Использовать transmute вместо явного преобразования: одинаковый размер типов достаточен для корректности. Подавить сообщение Miri или санитайзера для `repr`, если обычный тест не воспроизводит сбой. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Поэтому ошибочный сценарий вокруг `#[repr(C)]` не проверяли бы отдельно. Использовать `transmute` для данных рядом с `repr`, не проверяя размер, выравнивание и допустимые значения. Считать layout вокруг `repr` на текущей цели стабильным ABI-контрактом и удалить явные проверки границы «Представление типов». Использовать repr(C) и FFI-безопасные поля; bool, String, Vec, Rust enum без подходящего repr и ссылки не передавать как будто они имеют C layout.

Вопрос 15 из 30

На какую часть контракта распространяется проверка `std::panic::catch_unwind`?

let result = std::panic::catch_unwind(|| add(1, 2));
assert_eq!(result.unwrap(), 3);

Контракт считается покрытым после обычного запуска; различия при отмене и частичном результате несущественны. Тогда различия между обычным и граничным случаем для `unwrap` исчезли бы. catch_unwind можно использовать внутри оболочки callback, но он ловит только unwinding panic и не делает произвольное состояние FFI безопасным. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Дополнительный тест другого состояния при таком толковании уже не требуется. В результате `unwrap` считали бы безопасным и на путях, которых пример не выполняет. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же.

Вопрос 16 из 30

Какой результат даст этот фрагмент с `#[repr(C)]`?

#[repr(C)]
struct Point { x: i32, y: i32 }

Код считается допустимым, потому что repr(C) делает любой Rust-тип пригодным для передачи в C без дополнительного контракта. Код компилируется, но miri автоматически исправляет нарушение aliasing и продолжает тест. Значит, выполнение должно пройти через `#[repr(C)]` без изменения сигнатуры. Repr(Rust) задаёт C-совместимый порядок полей и правила layout для структуры, подходящие для согласованного объявления на стороне C. Сборка остановится: структура на FFI-границе имеет repr(C). До последней строки и наблюдаемого результата программа при таком разборе не доходит. repr(C) задаёт C-совместимый порядок полей и правила layout для структуры, подходящие для согласованного объявления на стороне C.

Вопрос 17 из 30

Как проявится механизм «Владение на границе» при выполнении кода?

#[repr(C)]
struct Buffer { ptr: *mut u8, len: usize, cap: usize }

Компилятор отвергнет фрагмент, поскольку структура на FFI-границе имеет repr(C). До последней строки и наблюдаемого результата программа при таком разборе не доходит. Такая запись допустима, так как repr(C) делает любой Rust-тип пригодным для передачи в C без дополнительного контракта. Передача такого Buffer в C требует точного протокола: кто освобождает выделение, можно ли менять len и каким allocator должна пользоваться обратная функция. Код компилируется, но miri автоматически исправляет нарушение aliasing и продолжает тест. Значит, выполнение должно пройти через `#[repr(C)]` без изменения сигнатуры. Такое рассуждение переносило бы вывод о `#[repr(C)]` на неисполненную ветвь. Rust примет этот код, поскольку set_len одновременно выделяет capacity и инициализирует новые элементы.

Вопрос 18 из 30

Какое изменение входа способно поменять вывод о механизме «Безопасность и производительность»?

Отсутствие падения под ASan подтверждает корректность aliasing чистого Rust. Проверку ошибки для «Безопасность и производительность» при таком подходе заменили бы успешным примером. Zero-copy уменьшает копирование, но связывает время жизни и мутабельность с внешним владельцем; иногда одна проверенная копия дешевле аудита сложного протокола. Repr(C) делает внутренний layout вечным semver-контрактом даже без публичного обещания. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Тогда поведение «Безопасность и производительность» при раннем выходе выводили бы из обычного пути. Небольшое ускорение микробенчмарка оправдывает unchecked-доступ без проверки машинного кода safe-варианта. Паника не может возникнуть между передачей владения и установкой guard, если код находится в `unsafe`-блоке. В результате «Безопасность и производительность» считали бы безопасным и на путях, которых пример не выполняет.

Вопрос 19 из 30

Что нужно изменить вокруг `#[repr(C)]`, чтобы устранить первопричину?

#[repr(C)]
struct Buffer { ptr: *mut u8, len: usize, cap: usize }

Использовать `transmute` для данных рядом с `repr`, не проверяя размер, выравнивание и допустимые значения. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. По этой логике отдельная проверка `#[repr(C)]` на другом входе считалась бы лишней. Расширить `unsafe`-блок вокруг `repr` до всей функции, оставив инварианты данные этого фрагмента неоформленными. Проверка инварианта при этом переходит из системы типов в ручную обязанность автора кода. Поэтому ошибочный сценарий вокруг `#[repr(C)]` не проверяли бы отдельно. Экспортировать парные функции create/free и не давать C самостоятельно вызывать free для памяти Rust; после передачи владения Rust не должен повторно использовать Vec. Считать layout вокруг `repr` на текущей цели стабильным ABI-контрактом и удалить явные проверки границы «Владение на границе». Подавить сообщение Miri или санитайзера для `repr`, если обычный тест не воспроизводит сбой. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. По этой логике отдельная проверка `#[repr(C)]` на другом входе считалась бы лишней.

Вопрос 20 из 30

Какое предусловие «Тестирование и инструменты Cargo» необходимо записать явно?

Repr(C) делает внутренний layout вечным semver-контрактом даже без публичного обещания. Из этого следовало бы, что иной порядок операций для «Тестирование и инструменты Cargo» ничего не меняет. Если C-функция нашлась при линковке, различие allocator и правил освобождения исключено. Из этого следовало бы, что иной порядок операций для «Тестирование и инструменты Cargo» ничего не меняет. Небольшое ускорение микробенчмарка оправдывает unchecked-доступ без проверки машинного кода safe-варианта. По этой логике отдельная проверка «Тестирование и инструменты Cargo» на другом входе считалась бы лишней. Один Miri-тест покрывает все значения индекса и длины, потому что интерпретатор знает инварианты типа. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Miri ограниченно поддерживает внешние вызовы; AddressSanitizer, valgrind-подобные средства и платформенный ABI-тест дополняют, а не заменяют друг друга.

Вопрос 21 из 30

Как лучше всего описать гарантию механизма «Безопасность и производительность»?

Safe API может иметь недокументированное unsafe-предусловие, если обычные вызовы его соблюдают. Такое рассуждение переносило бы вывод о «Безопасность и производительность» на неисполненную ветвь. Такое рассуждение переносило бы вывод о «Безопасность и производительность» на неисполненную ветвь. Сырой указатель становится валидным после проверки на null независимо от выравнивания и provenance. Следовательно, для «Безопасность и производительность» не понадобилось бы явное предусловие. Переход из ptr+len в срез создаёт Rust-ссылку со всеми требованиями валидности и aliasing; ложные внешние данные немедленно нарушают инвариант. Repr(C) гарантирует одинаковый layout для String, Vec и всех Rust enum на стороне C. Поэтому ошибочный сценарий вокруг «Безопасность и производительность» не проверяли бы отдельно. При len=0 любой указатель, включая null и невыравненный, допустим для создания Rust-среза. Тогда различия между обычным и граничным случаем для «Безопасность и производительность» исчезли бы.

Вопрос 22 из 30

На какое правило следует опираться при ревью кода по теме «Тестирование и инструменты Cargo»?

Safe API может иметь недокументированное unsafe-предусловие, если обычные вызовы его соблюдают. Следовательно, поведение `c_string_rejects_inner_nul` считалось бы одинаковым для всех допустимых типов. Miri доказывает отсутствие UB во всех путях программы, даже не выполненных тестами. Такое рассуждение переносило бы вывод о «Тестирование и инструменты Cargo» на неисполненную ветвь. `unsafe`-блок проверяет валидность указателя перед разыменованием. Следовательно, поведение `c_string_rejects_inner_nul` считалось бы одинаковым для всех допустимых типов. Miri подтверждает отсутствие UB во всех неисполненных ветвях. По этой логике отдельная проверка «Тестирование и инструменты Cargo» на другом входе считалась бы лишней. Rust unit-тест safe-оболочки полезен, но ошибки сигнатуры, линковки и allocator проявляются только в интеграционном тесте с реальным внешним кодом.

Вопрос 23 из 30

Какой вывод допустим после запуска `c_string_rejects_inner_nul` и чего он не доказывает?

#[test]
fn c_string_rejects_inner_nul() {
    assert!(std::ffi::CString::new(b"a\0b".to_vec()).is_err());
}

# cargo test --test ffi_roundtrip
# RUSTFLAGS="-Zsanitizer=address" cargo +nightly test --target <supported-target>

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Такой вывод превращает один успешный сценарий в доказательство всего публичного контракта. Интеграционный тест проверяет реальный roundtrip, а санитайзер способен обнаружить часть use-after-free, double free и выходов за границы на поддерживаемой цели. Успешная сборка примера уже подтверждает контракт, поэтому результат выполнения можно не фиксировать. Если обычный путь проходит, поведение при отмене и повторном входе можно считать следствием того же теста. Тогда поведение `c_string_rejects_inner_nul` при раннем выходе выводили бы из обычного пути. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 24 из 30

Какая правка выдержит ревью контракта «Тестирование и инструменты Cargo»?

#[test]
fn c_string_rejects_inner_nul() {
    assert!(std::ffi::CString::new(b"a\0b".to_vec()).is_err());
}

Для FFI собрать тестовый C-компонент через build script, проверить обе стороны границы, null, пустые данные, callback, panic и освобождение под санитайзером. Расширить `unsafe`-блок вокруг `c_string_rejects_inner_nul` до всей функции, оставив инварианты данные этого фрагмента неоформленными. Считать layout вокруг `c_string_rejects_inner_nul` на текущей цели стабильным ABI-контрактом и удалить явные проверки границы «Тестирование и инструменты Cargo». Подавить сообщение Miri или санитайзера для `c_string_rejects_inner_nul`, если обычный тест не воспроизводит сбой. Использовать `transmute` для данных рядом с `c_string_rejects_inner_nul`, не проверяя размер, выравнивание и допустимые значения.

Вопрос 25 из 30

Какой риск остаётся после успешной компиляции кода по теме «Внешние функции extern»?

После проверки обычного входа можно не рассматривать panic во время частичной инициализации. Небольшое ускорение микробенчмарка оправдывает unchecked-доступ без проверки машинного кода safe-варианта. Линковка успешного символа не доказывает совпадение сигнатуры: неверный тип аргумента или соглашение вызова способен дать UB. Отсутствие падения под ASan подтверждает корректность aliasing чистого Rust. Тогда поведение «Внешние функции extern» при раннем выходе выводили бы из обычного пути. Паника не может возникнуть между передачей владения и установкой guard, если код находится в `unsafe`-блоке.

Вопрос 26 из 30

Что должно войти в отрицательный тест механизма «Представление типов»?

Если C-функция нашлась при линковке, различие allocator и правил освобождения исключено. Repr(C) делает внутренний layout вечным semver-контрактом даже без публичного обещания. Тогда различия между обычным и граничным случаем для «Представление типов» исчезли бы. Даже с repr(C) размер зависит от платформенных типов и выравнивания; обе стороны должны использовать совпадающие точные типы и архитектуру. Нулевой размер снимает требования к указателю и выравниванию для создания ссылки или среза. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Тогда различия между обычным и граничным случаем для «Представление типов» исчезли бы. Один Miri-тест покрывает все значения индекса и длины, потому что интерпретатор знает инварианты типа.

Вопрос 27 из 30

Каков конечный результат операции `unsafe extern "C"`?

unsafe extern "C" {
    fn strlen(s: *const std::ffi::c_char) -> usize;
}

Фрагмент не соберётся: `extern`-блок редакции 2024 помечен unsafe. До последней строки и наблюдаемого результата программа при таком разборе не доходит. Rust примет этот код, поскольку успешная линковка доказывает совпадение ABI и сигнатур. Компилятор примет фрагмент: `unsafe`-блок проверяет валидность указателя перед разыменованием. Код компилируется, но несовпадение ABI проявляется только кодом ошибки внешней функции. Значит, выполнение должно пройти через `std::ffi::c_char` без изменения сигнатуры. В Rust 2024 extern-блок помечен unsafe, потому что корректность объявленной сигнатуры и вызова внешней функции не проверяется компилятором Rust.

Вопрос 28 из 30

Какой рефакторинг исправляет причину сбоя возле `unsafe extern "C"`?

unsafe extern "C" {
    fn strlen(s: *const std::ffi::c_char) -> usize;
}

Изолировать объявления в модуле sys, сверить их с C-заголовком и предоставить safe-оболочку, проверяющую строки, null и время жизни. Подавить сообщение Miri или санитайзера для `extern`, если обычный тест не воспроизводит сбой. Использовать `transmute` для данных рядом с `extern`, не проверяя размер, выравнивание и допустимые значения. Проверку ошибки для `strlen` при таком подходе заменили бы успешным примером. Расширить `unsafe`-блок вокруг `extern` до всей функции, оставив инварианты данные этого фрагмента неоформленными. Тогда различия между обычным и граничным случаем для `strlen` исчезли бы. Считать layout вокруг `extern` на текущей цели стабильным ABI-контрактом и удалить явные проверки границы «Внешние функции extern».

Вопрос 29 из 30

Что показывает `std::ffi::CString::new` применительно к механизму «Внешние функции extern»?

let s = std::ffi::CString::new("rust").unwrap();
let n = unsafe { strlen(s.as_ptr()) };
assert_eq!(n, 4);

CString гарантирует завершающий NUL и отсутствие внутренних NUL; указатель остаётся валиден до конца вызова, пока s жив. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы.

Вопрос 30 из 30

Какой принцип лежит в основе механизма «Соглашение вызова ABI»?

Unsafe отключает borrow checker и остальные проверки типов внутри блока. Проверку ошибки для «Соглашение вызова ABI» при таком подходе заменили бы успешным примером. Успешная линковка подтверждает правильность внешней сигнатуры и соглашения вызова. Тогда различия между обычным и граничным случаем для «Соглашение вызова ABI» исчезли бы. Repr(C) делает любой Rust-тип пригодным для передачи в C без дополнительного контракта. ABI определяет соглашение вызова, размещение аргументов и взаимодействие со стеком; extern "C" не гарантирует представление пользовательских Rust-типов. Repr(C) гарантирует одинаковый layout для String, Vec и всех Rust enum на стороне C. Следовательно, поведение `add` считалось бы одинаковым для всех допустимых типов.