ການປ່ອຍ Rust 1.81: ອຸປະສັກຕໍ່ການເຊື່ອມໂຍງ Rust Core Linux

ພາສາການຂຽນໂປລແກລມທີ່ມີຈຸດປະສົງທົ່ວໄປ Rust 1.81, ສ້າງຕັ້ງຂຶ້ນໂດຍໂຄງການ Mozilla ແຕ່ໃນປັດຈຸບັນໄດ້ຮັບການພັດທະນາພາຍໃຕ້ການອຸປະຖໍາຂອງອົງການເອກະລາດທີ່ບໍ່ຫວັງຜົນກໍາໄລ Rust Foundation, ໄດ້ຖືກປ່ອຍອອກມາ. ພາສາທີ່ເນັ້ນໃສ່ຄວາມປອດໄພຂອງຄວາມຊົງຈໍາແລະສະຫນອງວິທີການເພື່ອບັນລຸຄວາມຂະຫນານຂອງວຽກສູງໃນຂະນະທີ່ຫຼີກເວັ້ນການນໍາໃຊ້ເຄື່ອງເກັບຂີ້ເຫຍື້ອແລະເວລາແລ່ນ (runtime ຫຼຸດລົງເປັນພື້ນຖານເບື້ອງຕົ້ນແລະການຮັກສາຫ້ອງສະຫມຸດມາດຕະຖານ).

ວິທີການຈັດການຫນ່ວຍຄວາມຈໍາຂອງ Rust ຊ່ວຍປະຢັດນັກພັດທະນາຈາກຄວາມຜິດພາດໃນເວລາທີ່ manipulating pointers ແລະປ້ອງກັນບັນຫາທີ່ເກີດຂື້ນເນື່ອງຈາກການຈັດການຫນ່ວຍຄວາມຈໍາລະດັບຕ່ໍາ, ເຊັ່ນ: ການເຂົ້າເຖິງພື້ນທີ່ຫນ່ວຍຄວາມຈໍາຫຼັງຈາກທີ່ມັນໄດ້ຖືກປົດປ່ອຍ, dereferencing null pointers, buffer overruns, ແລະອື່ນໆ. ເພື່ອແຈກຢາຍຫ້ອງສະຫມຸດ, ສະຫນອງການກໍ່ສ້າງແລະການຄຸ້ມຄອງການເພິ່ງພາອາໄສ, ໂຄງການພັດທະນາຜູ້ຈັດການຊຸດສິນຄ້າ. ຄັງເກັບ crates.io ໄດ້ຮັບການສະຫນັບສະຫນູນສໍາລັບການເປັນເຈົ້າພາບຫ້ອງສະຫມຸດ.

ຄວາມປອດໄພຂອງຫນ່ວຍຄວາມຈໍາແມ່ນສະຫນອງໃຫ້ຢູ່ໃນ Rust ໃນເວລາລວບລວມໂດຍຜ່ານການກວດສອບການອ້າງອິງ, ການຕິດຕາມຄວາມເປັນເຈົ້າຂອງວັດຖຸ, ການຕິດຕາມອາຍຸຂອງວັດຖຸ (ຂອບເຂດ), ແລະການປະເມີນຄວາມຖືກຕ້ອງຂອງການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາໃນລະຫວ່າງການປະຕິບັດລະຫັດ. Rust ຍັງສະຫນອງການປ້ອງກັນການ overflows integer, ຮຽກຮ້ອງໃຫ້ມີການເລີ່ມຕົ້ນບັງຄັບຂອງຄ່າຕົວແປກ່ອນການນໍາໃຊ້, ຈັດການຄວາມຜິດພາດທີ່ດີກວ່າໃນຫ້ອງສະຫມຸດມາດຕະຖານ, ນໍາໃຊ້ແນວຄວາມຄິດຂອງການອ້າງອິງ immutable ແລະຕົວແປໂດຍຄ່າເລີ່ມຕົ້ນ, ສະຫນອງການພິມຄົງທີ່ທີ່ເຂັ້ມແຂງເພື່ອຫຼຸດຜ່ອນຄວາມຜິດພາດຢ່າງມີເຫດຜົນ.

ນະວັດຕະກໍາຕົ້ນຕໍ:

• ຫຼັກ::error::ລັກສະນະຄວາມຜິດພາດ, ເຊິ່ງກໍານົດຄໍາອະທິບາຍຄວາມຜິດພາດທີ່ສະແດງ, ໄດ້ຮັບການສະຖຽນລະພາບ. ການປ່ຽນແປງອະນຸຍາດໃຫ້ທ່ານໃຊ້ລັກສະນະ Error ດຽວໃນຫ້ອງສະຫມຸດຕ່າງໆ, ໂດຍບໍ່ຄໍານຶງເຖິງສະພາບແວດລ້ອມ, ລວມທັງໃນຫ້ອງສະຫມຸດທີ່ບໍ່ຕິດກັບຫ້ອງສະຫມຸດມາດຕະຖານ, ໂດຍໃຊ້ຄຸນລັກສະນະ "#![no_std]".
• ຟັງຊັນການຈັດຮຽງແບບຄົງທີ່ ແລະ ບໍ່ສະຖຽນໃນຫ້ອງສະໝຸດມາດຕະຖານໄດ້ຖືກປ່ຽນໄປໃຊ້ລະບົບສູດການຄິດໄລ່ໃໝ່ທີ່ສະແດງໃຫ້ເຫັນເຖິງປະສິດທິພາບທີ່ສູງຂຶ້ນ ແລະເວລາການລວບລວມຂໍ້ມູນຕ່ຳກວ່າ. ໃນການປະຕິບັດວິທີການຈັດຮຽງໃຫມ່, ມັນເປັນໄປໄດ້ທີ່ຈະກວດພົບປະເພດ Ord ທີ່ຖືກກໍານົດບໍ່ຖືກຕ້ອງແລະສະແດງຂໍ້ຜິດພາດ ( panic) ໃນກໍລະນີດັ່ງກ່າວແທນທີ່ຈະເປັນກຸ່ມຂໍ້ມູນແບບສຸ່ມ.
• Linter ປະຕິບັດລະດັບການກວດສອບໃຫມ່ "ຄາດຫວັງ" ("#[expect (lint)]"), ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດກວດສອບໄດ້ວ່າການກວດສອບໄດ້ສໍາເລັດແລະສະແດງຄໍາເຕືອນຖ້າການກວດສອບບໍ່ສໍາເລັດ (ເນື່ອງຈາກຄວາມຜິດພາດໃນການປະຕິບັດ. ຫຼືປິດການກວດສອບ). ຕົວຢ່າງ, ເມື່ອໂອນຍ້າຍຖານລະຫັດເພື່ອໃຊ້ການກວດສອບຂອງ Clippy's undocumented_unsafe_blocks, ທ່ານສາມາດລະບຸ "#[expect(clippy::undocumented_unsafe_blocks)]" ເພື່ອຮັບປະກັນວ່າບລັອກທີ່ບໍ່ປອດໄພທັງໝົດຖືກບັນທຶກໄວ້ໃນລະຫວ່າງການປ່ຽນ. Clippy ຍັງປະຕິບັດ clippy::allow_attributes ແລະ clippy::allow_attributes_without_reason checks, ເຮັດໃຫ້ມັນງ່າຍທີ່ຈະປ່ຽນແທນຄຸນສົມບັດ "#[allow]" ດ້ວຍ "#[expect(lint)]".
• ຄວາມສາມາດໃນການເອກະສານເຫດຜົນສໍາລັບການທົດແທນການກວດສອບລະດັບ (lint) ໄດ້ຖືກສະຫນອງໃຫ້, ໃຫ້ນັກພັດທະນາໃຫມ່ກ່ຽວກັບເຫດຜົນສໍາລັບການເພີ່ມການກວດສອບໂດຍສະເພາະ, ຜົນຜະລິດເປັນຂໍ້ຄວາມ compiler. ຕົວຢ່າງ: #![deny(clippy::float_arithmetic, ເຫດຜົນ = “ບໍ່ຮອງຮັບຮາດແວ float”)]
• ພາກສ່ວນໃຫມ່ຂອງ API ໄດ້ຖືກຍ້າຍໄປຢູ່ໃນປະເພດຂອງຄວາມຫມັ້ນຄົງ, ລວມທັງວິທີການແລະການຈັດຕັ້ງປະຕິບັດລັກສະນະຕ່າງໆແມ່ນມີຄວາມຫມັ້ນຄົງ:
  • ຫຼັກ:: ຄວາມຜິດພາດ
  • hint::assert_unchecked
  • fs::ມີຢູ່
  • AtomicBool::fetch_not
  • ໄລຍະເວລາ::abs_diff
  • IoSlice:: ລ່ວງຫນ້າ
  • IoSlice::advance_slices
  • IoSliceMut::ລ່ວງໜ້າ
  • IoSliceMut::advance_slices
  • ຂໍ້ມູນ PanicHook
  • PanicInfo::ຂໍ້ຄວາມ
  • ຂໍ້ຄວາມ Panic

  ຄຸນລັກສະນະ "const", ເຊິ່ງກໍານົດຄວາມເປັນໄປໄດ້ຂອງການນໍາໃຊ້ມັນໃນສະພາບການໃດກໍ່ຕາມແທນທີ່ຈະເປັນຄ່າຄົງທີ່, ຖືກນໍາໃຊ້ໃນຫນ້າທີ່:

  • char::from_u32_unchecked (ຟັງຊັນ)
  • char::from_u32_unchecked (ວິທີການ)
  • Cstr::count_bytes
  • CSstr::from_ptr

  ປະເພດ std::panic::PanicInfo ໄດ້ຖືກປ່ຽນຊື່ເປັນ std::panic::PanicHookInfo (ການທໍາງານຂອງຊື່ເກົ່າຖືກຮັກສາໄວ້, ແຕ່ຈາກສະບັບຕໍ່ໄປການນໍາໃຊ້ມັນຈະສົ່ງຜົນໃຫ້ມີການເຕືອນ). ໃນກໍລະນີນີ້, ຫຼັກ::panic::PanicInfo ຈະຍັງຄົງຢູ່, ແຕ່ຈະຖືກພັດທະນາເປັນປະເພດແຍກຕ່າງຫາກ. ການແຍກປະເພດຈະຊ່ວຍໃຫ້ທ່ານປະຕິບັດວິທີການທີ່ແຕກຕ່າງກັນໃນພວກມັນທີ່ສະເພາະກັບການປະຕິບັດໃນສະພາບການຂອງ snd ແລະ no_std.

• ການຫັນປ່ຽນໄປສູ່ C-unwind ABI ('extern "C-unwind"') ໄດ້ຖືກສໍາເລັດ, ເຊິ່ງແຕກຕ່າງຈາກ ABI ໂດຍບໍ່ມີ "-unwind" suffix ('extern "C"') ໂດຍການຮັກສາພຶດຕິກໍາທີ່ປອດໄພຖ້າຂະບວນການ unwinding ), ກະຕຸ້ນໃນເວລາທີ່ໂຄງການຂັດຂ້ອງຫຼືການຍົກເວັ້ນແບບ C++ ຖືກຖິ້ມ, ຂ້າມຂອບເຂດ ABI (ຕົວຢ່າງ, ເມື່ອຂໍ້ຍົກເວັ້ນທີ່ຖືກຖິ້ມໃນລະຫັດໃນພາສາການຂຽນໂປຼແກຼມຫນຶ່ງຖືກຍົກເລີກໂດຍການແຕະໃສ່ stack ທີ່ກ່ຽວຂ້ອງກັບລະຫັດໃນພາສາການຂຽນໂປຼແກຼມອື່ນ). ນັບຕັ້ງແຕ່ການປ່ອຍ Rust 1.81, 'extern "C"' ABI ໄດ້ຖືກເປີດໃຊ້ເພື່ອ crash ໃນ undetected unwinding.
• ລະດັບທີສາມຂອງການສະຫນັບສະຫນູນໄດ້ຖືກປະຕິບັດສໍາລັບແພລະຕະຟອມ i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2 -espidf, xtensa- esp32s3-espidf. ລະດັບທີສາມກ່ຽວຂ້ອງກັບການສະຫນັບສະຫນູນພື້ນຖານ, ແຕ່ບໍ່ມີການທົດສອບອັດຕະໂນມັດ, ການເຜີຍແຜ່ການກໍ່ສ້າງຢ່າງເປັນທາງການ, ຫຼືກວດເບິ່ງວ່າລະຫັດສາມາດສ້າງໄດ້.
• ລະດັບທີສອງຂອງການສະຫນັບສະຫນູນສໍາລັບເວທີເປົ້າຫມາຍ loongarch64-unknown-linux-musl ແລະ arm64ec-pc-windows-msvc ໄດ້ຖືກປະຕິບັດ. ລະດັບການສະຫນັບສະຫນູນທີສອງກ່ຽວຂ້ອງກັບການຮັບປະກັນການປະກອບ.
• ໄປ Linux-ລະບົບຕ່າງໆໃນແພລດຟອມ LoongArch ແມ່ນມາພ້ອມກັບຊຸດເຄື່ອງມື ແລະ ຕົວສ້າງໂປຣໄຟລ໌ທີ່ສົມບູນ.
• ແກ້ໄຂຊ່ອງໂຫວ່ (CVE-2024-43402) ໃນ std::process::Command ທີ່ມີຜົນກະທົບຕໍ່ແພລດຟອມເທົ່ານັ້ນ. Windows ແລະ ກຳຈັດວິທີແກ້ໄຂບັນຫາສຳລັບການໃຊ້ປະໂຫຍດຈາກຊ່ອງໂຫວ່ BatBadBut ທີ່ຖືກແກ້ໄຂກ່ອນໜ້ານີ້, ເຊິ່ງກ່ຽວຂ້ອງກັບການຈັດການຕົວອັກສອນພິເສດເມື່ອໃຊ້ Command::arg ແລະ Command::args calls, ເຊິ່ງຖືກອອກແບບມາເພື່ອສົ່ງອາກິວເມັນໄປຫາຂະບວນການໂດຍກົງໂດຍບໍ່ຕ້ອງປະມວນຜົນໂດຍຕົວແປຄຳສັ່ງ. ໃນຄວາມເປັນຈິງ, ເມື່ອໃຊ້ສະຄຣິບ bat ແລະ cmd, ຂະບວນການ cmd.exe ໄດ້ຖືກເປີດໃຊ້, ເຊິ່ງມີເຫດຜົນຂອງມັນເອງສຳລັບການແຍກອາກິວເມັນ. ການ bypass ແມ່ນອີງໃສ່ຄວາມຈິງທີ່ວ່າ Windows ລຶບຊ່ອງຫວ່າງ ແລະ ຈຸດນຳໜ້າໃນເສັ້ນທາງ, ເຊັ່ນ: ໄຟລ໌ທີ່ມີນາມສະກຸນ ".bat." ຈະຖືກປະມວນຜົນເປັນ ".bat".

ສິ່ງທີ່ໜ້າສັງເກດອີກຢ່າງໜຶ່ງຄືການອອກຈາກຕຳແໜ່ງຂອງ Wedson Almeida Filho ໃນຖານະຜູ້ຮັກສາໂຄງການຂອງ Rust ສຳລັບ Linux, ມີສ່ວນຮ່ວມໃນການປະຕິບັດ kernel Linux ເຄື່ອງມືພັດທະນາສຳລັບພາສາ Rust. ຫຼັງຈາກການອອກໄປຂອງ Wadson, ໂຄງການຍັງມີຜູ້ຮັກສາສອງຄົນຄື: Miguel Ojeda, ຜູ້ຂຽນ ແລະ ຜູ້ພັດທະນາຫຼັກຂອງ Rust-for-Linux, ແລະ Alex Gaynor, ອະດີດຜູ້ອຳນວຍການຂອງມູນນິທິຊອບແວ Python, ຜູ້ທີ່ໄດ້ປ່ຽນຈຸດສຸມຂອງລາວໄປສູ່ການສົ່ງເສີມ Rust. ຜູ້ຮັກສາທີ່ອອກໄປ, ຜູ້ທີ່ໄດ້ເຂົ້າຮ່ວມໂຄງການສີ່ປີກ່ອນ, ແມ່ນພະນັກງານ Microsoft ແລະເປັນຜູ້ຂຽນໄດຣເວີທົດລອງທີ່ຈັດຕັ້ງປະຕິບັດລະບົບໄຟລ໌ EXT2, ຂຽນໃນ Rust. ວຽກງານທີ່ຜ່ານມາຂອງ Almeida ໄດ້ສຸມໃສ່ການສ້າງເຄື່ອງມືສຳລັບການພັດທະນາລະບົບໄຟລ໌ໃນ Rust. ໃນປີນີ້, Almeida ໄດ້ປະກອບສ່ວນເຂົ້າໃນບ່ອນເກັບມ້ຽນ Rust-for-.Linux 17 commits (ສຳລັບການປຽບທຽບ, Miguel Ojeda ໄດ້ເພີ່ມ 53 commits).

ເຫດຜົນຂອງການອອກຈາກຕຳແໜ່ງແມ່ນການຂາດພະລັງງານ ແລະ ຄວາມກະຕືລືລົ້ນ, ເຊິ່ງເຄີຍມີຢູ່ເພື່ອຕອບສະໜອງຕໍ່ເລື່ອງໄຮ້ສາລະທີ່ບໍ່ແມ່ນດ້ານວິຊາການບາງຢ່າງ. ອີງຕາມ Almeida, ນັກພັດທະນາຖືກບັງຄັບໃຫ້ໃຊ້ພະລັງງານຫຼາຍໃນການໂຕ້ຖຽງກ່ຽວກັບບັນຫາທີ່ບໍ່ສຳຄັນທີ່ບ່ອນທຳລາຍເປົ້າໝາຍໂດຍລວມທີ່ສຳຄັນກວ່າ. Almeida ສືບຕໍ່ເຊື່ອວ່າອະນາຄົດຂອງ kernels ແມ່ນຢູ່ໃນການໃຊ້ພາສາທີ່ປອດໄພຕໍ່ຄວາມຈຳ, ແລະ ຖ້າຊຸມຊົນນັກພັດທະນາ Linux ແລ້ວຈະບໍ່ເຂົ້າໃຈເລື່ອງນີ້ Linux ຈະຖືກທົດແທນໂດຍ kernel ອື່ນໆ, ດັ່ງທີ່ໄດ້ເກີດຂຶ້ນກັບ Unix ໃນເວລານັ້ນ.

ຜູ້ສະໜັບສະໜູນໂຄງການ Rust-for-Linux ໄດ້ປະເຊີນກັບຄວາມຕ້ອງການທີ່ຈະເອົາຊະນະການຕໍ່ຕ້ານຈາກນັກພັດທະນາ kernel ທີ່ມີປະສົບການມາດົນນານ ຜູ້ທີ່ບໍ່ເຫັນວ່າມີຄວາມຈຳເປັນທີ່ຈະຮຽນຮູ້ພາສາໃໝ່. ໃນຈົດໝາຍລາອອກຂອງລາວ, Almeida ໄດ້ຍົກຕົວຢ່າງການສົນທະນາທີ່ເກີດຂຶ້ນໃນລະຫວ່າງການນຳສະເໜີຂອງ Almeida ກັບ Kent Overstreet ທີ່Linux "ການເກັບຮັກສາ, ລະບົບໄຟລ໌, ການຄຸ້ມຄອງໜ່ວຍຄວາມຈຳ, ແລະ ກອງປະຊຸມສຸດຍອດ BPF" ແລະ ໄດ້ອຸທິດໃຫ້ແກ່ການນຳໃຊ້ Rust ສຳລັບການພັດທະນາລະບົບໄຟລ໌. ຄວາມພະຍາຍາມໃນການຈັດຕັ້ງປະຕິບັດ Rust ໄດ້ຖືກວິພາກວິຈານໂດຍ Ted Ts'o, ຜູ້ຂຽນລະບົບໄຟລ໌ ext2/ext3/ext4, ຜູ້ທີ່ໄດ້ປຽບທຽບ Rust-for-Linux ດ້ວຍຄວາມພະຍາຍາມທີ່ຈະບັງຄັບໃຫ້ທຸກຄົນຍອມຮັບສາສະໜາ Rust.

ເພື່ອຕອບສະຫນອງຄວາມຕັ້ງໃຈຂອງ Almeida ທີ່ຈະສ້າງ wrapper ປະມານການໂຕ້ຕອບຂອງລະບົບໄຟລ໌ທີ່ຂຽນໃນ C ສໍາລັບການນໍາໃຊ້ໃນລະຫັດ Rust, Ted Tso ຊີ້ໃຫ້ເຫັນວ່າ wrapper ດັ່ງກ່າວ inevitably ນໍາໄປສູ່ການບັນຫາ, ເນື່ອງຈາກວ່າການປ່ຽນແປງໃດໆກັບ C interfaces ແລະ refactoring ຈະຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງຜູກມັດສໍາລັບ. Rust ແລະລາວບໍ່ຕ້ອງການຮັບຜິດຊອບທີ່ບໍ່ຈໍາເປັນສໍາລັບການແກ້ໄຂບັນຫາໃນລະຫັດ Rust ແລະຕິດຕາມສະຖານະຂອງການຜູກມັດ Rust. ລະຫັດ C ແມ່ນພັດທະນາຢ່າງຕໍ່ເນື່ອງ, ແລະຖ້າການປ່ຽນແປງຂອງມັນທໍາລາຍການເຮັດວຽກຂອງກອບ Rust, ມັນຈະນໍາໄປສູ່ການຂັດຂວາງການເຮັດວຽກຂອງລະບົບໄຟລ໌ທັງຫມົດທີ່ຕິດກັບກອບນີ້.

Ted ຍັງເຊື່ອວ່າໃນອະນາຄົດອັນໃກ້ນີ້, ການຜູກມັດສຳລັບ Rust ຈະຍັງຄົງເປັນອັນດັບສອງ ແລະ ບັນຫາໃນການຜູກມັດຈະເປັນພຽງບັນຫາທີ່ໜ້າເສົ້າໃຈສຳລັບນັກພັດທະນາ Rust ເທົ່ານັ້ນ.Linux, ແລະບໍ່ແມ່ນສຳລັບຊຸມຊົນພັດທະນາລະບົບໄຟລ໌ kernel. ມັນໄດ້ຖືກຊີ້ໃຫ້ເຫັນວ່າບໍ່ແມ່ນນັກພັດທະນາທຸກຄົນມີຄວາມຕັ້ງໃຈທີ່ຈະຮຽນຮູ້ Rust, ແລະດັ່ງນັ້ນ, ຫຼັງຈາກເຮັດການປ່ຽນແປງທີ່ມີຜົນກະທົບຕໍ່ລະຫັດອື່ນໆ, ພວກເຂົາຈະສາມາດອັບເດດລະຫັດ C ທີ່ຂຶ້ນກັບເທົ່ານັ້ນ, ແຕ່ຈະບໍ່ສາມາດແກ້ໄຂການຜູກມັດ Rust ໄດ້, ຍ້ອນວ່າພວກເຂົາບໍ່ຮູ້ Rust. James Bottomley, ຜູ້ຮັກສາລະບົບຍ່ອຍ SCSI, ຍັງໄດ້ເຂົ້າຮ່ວມການສົນທະນາ, ໂດຍກ່າວວ່າ semantics ຖືກເຂົ້າລະຫັດເຂົ້າໃນການຜູກມັດຫຼາຍເທົ່າໃດ, ພວກມັນກໍ່ຈະມີຄວາມບອບບາງຫຼາຍຂຶ້ນໃນແງ່ຂອງການຊິ້ງຂໍ້ມູນ.

ໃນຂະນະດຽວກັນ, Google, ເຊິ່ງໃນປີກາຍນີ້ໄດ້ຂຽນເຟີມແວ pvmfm ທີ່ໃຊ້ໃນ ເຄື່ອງ virtual, ເປີດຕົວໃນແພລດຟອມ Android, ໄດ້ແບ່ງປັນປະສົບການຂອງນາງທີ່ຄ່ອຍໆລວມລະຫັດ Rust ເຂົ້າໃນເຟີມແວທີ່ມີຢູ່ແລ້ວທີ່ຂຽນດ້ວຍພາສາ C ຫຼື C++. ນາງໄດ້ສາທິດວິທີການປັບປຸງຄວາມປອດໄພຂອງເຟີມແວໄດ້ຢ່າງຫຼວງຫຼາຍໂດຍການສ້າງອົງປະກອບທົດແທນທີ່ຄືກັນທາງດ້ານໜ້າທີ່ຂຽນດ້ວຍພາສາ Rust. ເມື່ອນຳໃຊ້ Rust, ນາງໄດ້ສະເໜີໃຫ້ສຸມໃສ່ການໃຊ້ Rust ສຳລັບລະຫັດໃໝ່ ແລະ ລະຫັດທີ່ປະຕິບັດໜ້າທີ່ທີ່ສຳຄັນທາງດ້ານຄວາມປອດໄພ (ຕົວຢ່າງ, ລະຫັດສຳລັບການປະມວນຜົນຂໍ້ມູນພາຍນອກທີ່ໄດ້ຮັບຈາກແຫຼ່ງທີ່ບໍ່ໜ້າເຊື່ອຖື). ເພື່ອລວມລະຫັດ Rust ແລະ C, ນາງໄດ້ສະເໜີໃຫ້ໃຊ້ຊິມທີ່ແປການໂທລະຫວ່າງ Rust ແລະ C APIs (C API ຖືກສົ່ງອອກເພື່ອໃຊ້ໃນລະຫັດ Rust ແລະໃນທາງກັບກັນ), ເຊິ່ງຊ່ວຍໃຫ້ສາມາດຂຽນຄືນອົງປະກອບ API ໃນ Rust ໄດ້ເທື່ອລະກ້າວ.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru