การเปิดตัวของภาษาการเขียนโปรแกรมสำหรับวัตถุประสงค์ทั่วไปของ Rust 1.81 ซึ่งก่อตั้งโดยโครงการ Mozilla แต่ปัจจุบันได้รับการพัฒนาภายใต้การอุปถัมภ์ขององค์กรอิสระ Rust Foundation ที่ไม่แสวงหาผลกำไร ได้รับการเผยแพร่แล้ว ภาษานี้เน้นไปที่ความปลอดภัยของหน่วยความจำและให้แนวทางเพื่อให้ได้งานที่มีความเท่าเทียมกันสูง ในขณะที่หลีกเลี่ยงการใช้ตัวรวบรวมขยะและรันไทม์ (รันไทม์จะลดลงเหลือเพียงการเริ่มต้นพื้นฐานและการบำรุงรักษาไลบรารีมาตรฐาน)
วิธีการจัดการหน่วยความจำของ Rust ช่วยนักพัฒนาจากข้อผิดพลาดเมื่อจัดการพอยน์เตอร์และป้องกันปัญหาที่เกิดขึ้นเนื่องจากการจัดการหน่วยความจำระดับต่ำ เช่น การเข้าถึงพื้นที่หน่วยความจำหลังจากปล่อยให้ว่าง การยกเลิกการอ้างอิงพอยน์เตอร์ null บัฟเฟอร์เกิน เป็นต้น เพื่อแจกจ่ายไลบรารี่ จัดเตรียมการสร้างและจัดการการอ้างอิง โครงการพัฒนาตัวจัดการแพ็คเกจสินค้า ที่เก็บ crates.io รองรับการโฮสต์ไลบรารี
ความปลอดภัยของหน่วยความจำมีให้ใน Rust ณ เวลาคอมไพล์ผ่านการตรวจสอบการอ้างอิง การติดตามความเป็นเจ้าของออบเจกต์ การติดตามอายุอ็อบเจ็กต์ (ขอบเขต) และการประเมินความถูกต้องของการเข้าถึงหน่วยความจำระหว่างการดำเนินการโค้ด สนิมยังให้การป้องกันการล้นของจำนวนเต็ม, จำเป็นต้องมีการกำหนดค่าเริ่มต้นที่จำเป็นของค่าตัวแปรก่อนใช้งาน, จัดการข้อผิดพลาดได้ดีขึ้นในไลบรารีมาตรฐาน, ใช้แนวคิดของการอ้างอิงและตัวแปรที่ไม่เปลี่ยนรูปแบบตามค่าเริ่มต้น, เสนอการพิมพ์แบบคงที่ที่แข็งแกร่งเพื่อลดข้อผิดพลาดเชิงตรรกะ
นวัตกรรมหลัก:
- ลักษณะหลัก::error::Error ซึ่งกำหนดคำอธิบายข้อผิดพลาดที่แสดง ได้รับความเสถียรแล้ว การเปลี่ยนแปลงทำให้คุณสามารถใช้คุณลักษณะข้อผิดพลาดเดียวในไลบรารีต่างๆ โดยไม่คำนึงถึงสภาพแวดล้อม รวมถึงในไลบรารีที่ไม่เชื่อมโยงกับไลบรารีมาตรฐาน โดยใช้แอตทริบิวต์ “#![no_std]”
- ฟังก์ชันการเรียงลำดับที่เสถียรและไม่เสถียรในไลบรารีมาตรฐานได้รับการแปลงให้ใช้อัลกอริธึมใหม่ที่แสดงประสิทธิภาพที่สูงขึ้นและเวลาในการคอมไพล์ที่ลดลง ในการใช้งานอัลกอริธึมการเรียงลำดับใหม่ เป็นไปได้ที่จะตรวจจับประเภท Ord ที่กำหนดไว้อย่างไม่ถูกต้อง และแสดงข้อผิดพลาด (ตื่นตระหนก) ในกรณีดังกล่าว แทนที่จะจัดกลุ่มข้อมูลที่สุ่ม
- Linter ใช้ระดับการตรวจสอบใหม่ “expect” (“#[expect(lint)]”) ซึ่งช่วยให้คุณตรวจสอบว่าการตรวจสอบเสร็จสมบูรณ์แล้ว และแสดงคำเตือนหากการตรวจสอบไม่เสร็จสมบูรณ์ (เนื่องจากข้อผิดพลาดในการใช้งาน หรือปิดการใช้งานการตรวจสอบ) ตัวอย่างเช่น เมื่อย้ายฐานรหัสเพื่อใช้การตรวจสอบ undocumented_unsafe_blocks ของ Clippy คุณสามารถระบุ "#[expect(clippy::undocumented_unsafe_blocks)]" เพื่อให้แน่ใจว่าบล็อกที่ไม่ปลอดภัยทั้งหมดได้รับการบันทึกไว้ในระหว่างการเปลี่ยนแปลง นอกจากนี้ Clippy ยังใช้การตรวจสอบ clippy::allow_attributes และ clippy::allow_attributes_without_reason ทำให้ง่ายต่อการแทนที่แอตทริบิวต์ "#[allow]" ด้วย "#[expect(lint)]"
- มีความสามารถในการจัดทำเอกสารเหตุผลในการเปลี่ยนระดับการตรวจสอบ (ผ้าสำลี) เพื่อให้นักพัฒนาใหม่ทราบข้อมูลเกี่ยวกับเหตุผลในการเพิ่มการตรวจสอบเฉพาะ ส่งออกเป็นข้อความคอมไพเลอร์ ตัวอย่างเช่น: #![deny(clippy::float_arithmetic, problems = “no hardware float support”)]
- ส่วนใหม่ของ API ถูกย้ายไปยังหมวดหมู่ของความเสถียร ซึ่งรวมถึงวิธีการและการใช้งานลักษณะต่างๆ ที่ได้รับการทำให้เสถียร:
- หลัก::ข้อผิดพลาด
- คำใบ้::assert_unchecked
- fs::มีอยู่จริง
- AtomicBool::fetch_not
- ระยะเวลา::abs_diff
- IoSlice::ขั้นสูง
- IoSlice::advance_slices
- IoSliceMut::ขั้นสูง
- IoSliceMut::advance_slices
- ข้อมูล PanicHook
- PanicInfo::ข้อความ
- ข้อความตื่นตระหนก
คุณลักษณะ “const” ซึ่งกำหนดความเป็นไปได้ในการใช้งานในบริบทใดๆ แทนที่จะเป็นค่าคงที่ ถูกใช้ในฟังก์ชัน:
- ถ่าน :: from_u32_unchecked (ฟังก์ชั่น)
- ถ่าน :: from_u32_unchecked (วิธีการ)
- CStr::count_bytes
- CStr::from_ptr
ประเภท std::panic::PanicInfo ได้รับการเปลี่ยนชื่อเป็น std::panic::PanicHookInfo (การทำงานของชื่อเก่าจะยังคงอยู่ แต่จากเวอร์ชันถัดไปการใช้งานจะส่งผลให้เกิดคำเตือน) ในกรณีนี้ core::panic::PanicInfo จะยังคงเหมือนเดิม แต่จะได้รับการพัฒนาเป็นประเภทแยกต่างหาก การแยกประเภทจะช่วยให้คุณสามารถใช้วิธีการที่แตกต่างกันในประเภทที่เฉพาะเจาะจงสำหรับการดำเนินการในบริบทของ snd และ no_std
- การเปลี่ยนไปใช้ C-unwind ABI ('extern "C-unwind"') เสร็จสิ้นแล้ว ซึ่งแตกต่างจาก ABI ที่ไม่มีคำต่อท้าย "-unwind" ('extern "C"') โดยการรักษาพฤติกรรมที่ปลอดภัยหากกระบวนการคลี่คลาย ) จะถูกทริกเกอร์เมื่อโปรแกรมหยุดทำงานหรือมีข้อยกเว้นแบบ C++ เกิดขึ้น ข้ามขอบเขต ABI (ตัวอย่างเช่น เมื่อข้อยกเว้นที่เกิดขึ้นในโค้ดในภาษาการเขียนโปรแกรมหนึ่งถูกคลายออกโดยการแตะสแต็กที่เกี่ยวข้องกับโค้ดในภาษาการเขียนโปรแกรมอื่น) นับตั้งแต่เปิดตัว Rust 1.81 ABI 'extern "C"' ได้ถูกเปิดใช้งานให้หยุดทำงานเมื่อไม่ได้ตรวจพบการคลี่คลาย
- การสนับสนุนระดับที่สามได้ถูกนำมาใช้สำหรับแพลตฟอร์ม 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, рассчитанных на прямую передачу процессу аргументов, без их обработки командным интерпретатором. На деле при запуске bat- и cmd-сценариев запускался процесс cmd.exe, имеющий собственную логику разделения аргументов. Обход защиты основан на том, что Windows удаляет лидирующие пробелы и точки в путях, т.е. файл с расширением «.bat. .» обрабатывается как «.bat».
Кроме того, можно отметить уход Уэдсона Алмейда Фильо (Wedson Almeida Filho) с поста сопровождающего проект Rust for Linux, занимающийся внедрением в ядро Linux средств для разработки на языке Rust. После ухода Уэдсона у проекта остались ещё два сопровождающих — Мигель Охеда (Miguel Ojeda), автор и основной разработчик проекта Rust-for-Linux, и Алекс Гейнор (Alex Gaynor), бывший директор организации Python Software Foundation, переключившийся на продвижение Rust. Ушедший сопровождающий, который подключился к проекту 4 года назад, является сотрудником компании Microsoft и автором экспериментального драйвера с реализацией ФС EXT2, написанного на языке Rust. Последнее время работа Алмейда была сосредоточена на создании средств для разработки файловых систем на языке Rust. В этом году Алмейда внёс в репозиторий Rust-for-Linux 17 коммитов (для сравнения Мигель Охеда добавил 53 коммита).
В качестве причины ухода упоминается нехватка сил и энтузиазма, которые когда-то были для реагирования на некоторые бредни нетехнического характера (nontechnical nonsense). По мнению Алмейда, разработчики вынуждены тратить много сил на споры по несущественным вопросам, сводящим на нет более важную глобальную цель. Алмейда продолжает верить, что будущее ядер за использованием языков, обеспечивающих безопасную работу с памятью, и если сообщество разработчиков Linux не поймёт это, то Linux будет вытеснен каким-то другим ядром, как в своё время произошло с Unix.
Сторонники проекта Rust-for-Linux столкнулись с необходимостью преодолевать сопротивление со стороны маститых старых разработчиков ядра, которые не видят необходимости в изучении нового языка. В своём письме об отставке Алмейда в качестве примера приводит ссылку на дискуссию, которая состоялась во время выступления Алмейда и Кента Оверстрита (Kent Overstreet) на конференции «Linux Storage, Filesystem, Memory-Management, and BPF Summit» и была посвящена использованию Rust для разработки файловых систем. Деятельность по внедрению Rust раскритиковал Тед Цо (Ted Ts’o), автор файловых систем ext2/ext3/ext4, который сравнил инициативу Rust-for-Linux c попыткой заставить всех принять религию Rust.
เพื่อตอบสนองต่อความตั้งใจของ Almeida ในการสร้าง wrapper รอบอินเทอร์เฟซระบบไฟล์ที่เขียนด้วยภาษา C เพื่อใช้ในโค้ด Rust Ted Tso ชี้ให้เห็นว่า wrapper ดังกล่าวจะนำไปสู่ปัญหาอย่างหลีกเลี่ยงไม่ได้ เนื่องจากการเปลี่ยนแปลงใด ๆ ในอินเทอร์เฟซ C และการปรับโครงสร้างใหม่จะต้องมีการเปลี่ยนแปลงการเชื่อมโยงสำหรับ Rust และเขาไม่ต้องการรับผิดชอบที่ไม่จำเป็นในการแก้ไขปัญหาในโค้ด Rust และติดตามสถานะของการรวม Rust รหัส C มีการพัฒนาอย่างต่อเนื่อง และหากการเปลี่ยนแปลงดังกล่าวขัดขวางการทำงานของเฟรมเวิร์ก Rust ก็จะนำไปสู่การหยุดชะงักของระบบไฟล์ทั้งหมดที่เกี่ยวข้องกับเฟรมเวิร์กนี้
Тед также считает, что в обозримом будущем обвязка для Rust останется второстепенной и возникновение проблем в биндингах будет головной болью только для разработчиков Rust-for-Linux, а не для сообщества разработчиков файловых систем в ядре. Указано, что не все разработчики собираются изучать Rust и поэтому после внесения влияющих на другой код изменений, они смогут обновить только зависящий код на Си, но не смогут исправить Rust-обвязки, так как не знают Rust. К дискуссии также присоединился Джеймс Боттомли (James Bottomley), сопровождающий подсистему SCSI, который сказал, что чем больше семантики кодируется в обвязках, тем они становятся более ломкими с точки зрения обеспечения синхронизации.
ในขณะเดียวกัน Google ซึ่งเมื่อปีที่แล้วได้เขียนเฟิร์มแวร์ pvmfm ที่ใช้ในใหม่ทั้งหมด เครื่องเสมือน, запускаемых в платформе Android, поделилась опытом постепенного включения кода на языке Rust в существующие прошивки, изначально написанные на C или C++. Показано, как можно существенно повысить защищённость прошивок, создавая идентичные по функциональности компоненты-замены, написанные на языке Rust. Основное внимание при внедрении Rust предлагается уделять использованию Rust для нового кода и кода, выполняющего функции, критические с точки зрения безопасности (например, код по обработке внешних данных, получаемых из не заслуживающих доверия источников). Для интеграции кода на Rust и C предлагается использовать прослойки (shim), транслирующие вызовы между API на Rust и C (C API экспортируется для использования в коде на Rust и наоборот), которые позволяют поэтапно переписывать элементы API на Rust.
ที่มา: opennet.ru
