Проблемы Rust

@~~RatPoison~~ · 04.03.2021, 13:30. **Показов** 4760. **Ответов** 31

Author24 — интернет-сервис помощи студентам

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

Язык Rust предлагает много полезных инструментов своим пользователям.
Но и ставит препоны им он тоже довольно часто.
Самый простой пример - Rust не позволяет считать просто число из входного потока.
Вместо этого нам предлагают читать строки.

пример:

C

use std::io::{self, prelude::*};
 
fn main() {
   
   let mut number = String::new();
   
   io::stdin().read_line(&mut buf).unwrap();
 
   println!("{}", num);
}

Но что, если нам надо хранить входные данные именно как число, а не как строку?
Нам предлагается ее "распарсить".

C

use std::io::{self, prelude::*};
 
fn main() {
   
   let mut number = String::new();
   let mut digits = 0;
   
    io::stdin().read_line(&mut number).unwrap();
    digits = number.trim().parse::<i32>().unwrap(); //перед тем, как парсить нужно убрать из строки все лишнее, чтобы остались только цифры.
    //для этого применяем еще и  метод trim() к строке иначе получим ошибку!
    println!("{}", digits);
 
}

Все прекрасно.
Но что если введенное число больше i32?
Опять получим ошибку и панику.
Как быть? Парсить как самый большой тип, а потом приводить к нужному?
Тут опять возникают вопросы, так как не все типы можно приводить друг к другу.

Остаётся применять костыли и парсить саму строку именно как строку.

Например если я хочу получить число u8, то можно посчитать длину строки.

C

1
2
3

if number.len() > 3  {
  ...
}

И если она превышает 3 символа(без учёта символа конца строки), то это число уже точно не попадает в диапазон типа u8.
Тогда вам придётся знать и помнить диапазоны значений или вызывать их из библиотеки.

продолжение следует...

Добавлено через 46 минут
З.Ы. можно использовать синтаксис match, но проблема в том, что match должен возвращать один и тот же тип из всех ветвей: вернуть число или сообщить об ощибке просто так не выйдет. Придется создавать новый тип, который будет служить контейнером.
А вот синтаксис if let подойдет в самый раз. И не придется считать длинну строки.

Vourhey · 04.03.2021, 13:41

Сообщение от RatPoison

Опять получим ошибку и панику.

И это прекрасно. Жаль, что паника не в любом языке. Обрабатывай ошибки и говори о них пользователю.

@Curry · 04.03.2021, 16:25

Сообщение от RatPoison

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

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

Добавлено через 1 минуту
А ещё, кстати, предлагаю писать челобитную Микаэлю от нескольких человек чтобы он повелел прикрутить синтаксис rust-а к форуму.

@~~RatPoison~~ · 04.03.2021, 19:18 **[ТС]**

Сообщение от Vourhey

И это прекрасно. Жаль, что паника не в любом языке. Обрабатывай ошибки и говори о них пользователю.

Я забыл про синтексис if let, который тут подходит как никогда.

C

use std::io::{self, prelude::*};
 
fn main() {
   
   let mut number = String::new();
   let mut digits: u8 = 0;
 
  loop {
    print!("Число: ");
    io::stdout().flush().unwrap();
    io::stdin().read_line(&mut number).unwrap();
    
    if let Ok(n) = number.trim().parse::<u8>() {
      digits = n;
      break;
    } else {
      println!("Вводимое число не должно быть больше 255");
      number.clear();
      continue;
    }
 
  }
 
   println!("{}", digits);
}

Добавлено через 31 секунду

Сообщение от Curry

прикрутить синтаксис rust-а к форуму.

думаю прикрутят, когда в ветке будет чуть больше, чем 3 человека)

@IamLost · 05.03.2021, 14:04

Сообщение от RatPoison

Но что если введенное число больше i32?

А что если введённое число состоит из 10 тысяч знаков? Вы скажете такого не может быть? Я скажу что может, если число может быть больше 32бит, то что мне мешает ввести тысячи знаков?

Сообщение от RatPoison

Как быть? Парсить как самый большой тип, а потом приводить к нужному?

Нет, разумно оценивать что ваша программа будет делать и с какими данными она будет работать? И если пользователь вздумал ввести число, которое больше чем 32бит сообщить ему об этом и попросить ввести корректные данные?

Сообщение от RatPoison

продолжение следует...

Да, давайте дальше, так как это назвать проблемой языка можно разве с натяжкой. И вообще это разве проблема языка, а не проблема его стандартной библиотеки?

@~~RatPoison~~ · 05.03.2021, 14:28 **[ТС]**

Сообщение от IamLost

А что если введённое число состоит из 10 тысяч знаков? Вы скажете такого не может быть? Я скажу что может, если число может быть больше 32бит, то что мне мешает ввести тысячи знаков?

Я вообще-то про это и говорил.

Сообщение от IamLost

Нет, разумно оценивать что ваша программа будет делать и с какими данными она будет работать?

И про это тоже.

Сообщение от IamLost

И если пользователь вздумал ввести число, которое больше чем 32бит сообщить ему об этом и попросить ввести корректные данные?

Как раз и рассуждал как это сделать без изобретения велосипеда. Синтаксис if let тут весьма помогает.

Сообщение от IamLost

И вообще это разве проблема языка, а не проблема его стандартной библиотеки?

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

Если для вас это не проблема, то давайте почитайте соседнюю тему о возможной уязвимости при чтении входных данных в строку или в вектор.
А если вы из С пришли в Rust и хотите сделать что-то типа этого:

C

struct Person {
   name [u8; 50],
   surname [u8, 50]
}

То этот код у вас не скомпенсируется, так как длина массива в структурах не может быть больше 32.
Как я понимаю, это сделано потому, что можно сделать так:

C

struct Person<T> {
   name [T; 50],
   surname [T, 50]
}

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

@IamLost · 05.03.2021, 16:19

Сообщение от RatPoison

Если для вас это не проблема, то давайте почитайте соседнюю тему о возможной уязвимости при чтении входных данных в строку или в вектор.
А если вы из С пришли в Rust и хотите сделать что-то типа этого:

Я тупой, я перечитал 3 раза и не понял в чём проблема. В том, что программа упадёт? В каком ЯП она не упадёт, если мы будем вводить строку действительно произвольной длины? Ввод же окончится после того как пользователь нажмёт Enter? Соотвественно в теории я могу ввести строку, в которой будет больше байт чем памяти компьютера.

@~~RatPoison~~ · 05.03.2021, 18:21 **[ТС]**

Сообщение от IamLost

Ввод же окончится после того как пользователь нажмёт Enter?

Если говорить о методе read-line - то да. Точнее пока read-line не встретит символ новой строки - '\n', так как данные можно читать из любого потока - файл, tcp соединение и тд.

Сообщение от IamLost

В каком ЯП она не упадёт, если мы будем вводить строку действительно произвольной длины?

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

Сообщение от IamLost

Соотвественно в теории я могу ввести строку, в которой будет больше байт чем памяти компьютера.

Ну всю память навряд ли удастся занять. Программа будет запрашивать у ОС память снова и снова, пока ОС не скажет: "Хватит".

@Curry · 05.03.2021, 19:25

Сообщение от RatPoison

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

Язык не позволяет написать свой крейт или найти подходящий?

Сообщение от RatPoison

данные можно читать из любого потока - файл, tcp соединение

В 2021 не стоит обрабатывать большие данные через стандартные потоки.

Сообщение от RatPoison

от этого должна быть защита иначе это потенциальное место для возможных атак.

Вам же написали - читайте в буфер. Сами же нашли from_utf8_lossy. А если посмотреть как она реализована, то увидим что там используется модуль lossy, к сожалению, пока экспериментальный. А так то можно им читать входной буфер пока там полные UTF-8 символы. А остаток оставлять пока получения следующих данных.

@~~RatPoison~~ · 08.03.2021, 19:36 **[ТС]**

Если вы когда-нибудь имели дело с другими системными языками программирования, то наверняка заметили, что в Rust нет такой, казалось бы, простой и элементарной вещи, как функция закрывающая файл. Пользователям предлагается иметь дело либо с областями видимости и ждать, пока указатель на открытый фал сам "дропнится", либо воспользоваться функций drop напрямую. Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой.

@Curry · 08.03.2021, 21:05

Сообщение от RatPoison

Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой.

А поискать?
https://docs.rs/close-file/0.1.0/close_file/

@~~RatPoison~~ · 08.03.2021, 21:10 **[ТС]**

Сообщение от Curry

А поискать?

Отдельный крейт для этой функции? По-моему несерьезно. Эта функция должна быть в стандартной библиотеке.
Интересно, она clib::fclose вызывает?

@Curry · 08.03.2021, 22:03

Сообщение от RatPoison

Отдельный крейт для этой функции? По-моему несерьезно. Эта функция должна быть в стандартной библиотеке.

Ну, сырой rust по факту.
"Всё равно его не брошу
Потому что он хороший." (с) А. Барто.

Ничего нет страшного, если крейт в зависимости добавить.

Сообщение от RatPoison

Интересно, она clib::fclose вызывает?

Исходник посмотреть тоже никак?
Для линя вызывает. Для винды kernel32::CloseHandle.

@~~RatPoison~~ · 08.03.2021, 22:53 **[ТС]**

Сообщение от Curry

Ничего нет страшного, если крейт в зависимости добавить.

новичок не будет использовать сторонние крейты. он будет использовать стандартную библиотеку.
Если Rust за безопасность, то это должно прослеживаться везде, а не быть просто на словах.
Мы же хотим пользоваться хорошим языком ЯП.

@Curry · 09.03.2021, 00:48

RatPoison, если хотите, поэкспериментируйте с sync_all, может быть его достаточно.

@~~RatPoison~~ · 09.03.2021, 11:22 **[ТС]**

Curry, да, я читал.
этот метод время кушает и бывает избыточен.

Vourhey · 09.03.2021, 11:31

Сообщение от RatPoison

Если вы когда-нибудь имели дело с другими системными языками программирования, то наверняка заметили, что в Rust нет такой, казалось бы, простой и элементарной вещи, как функция закрывающая файл. Пользователям предлагается иметь дело либо с областями видимости и ждать, пока указатель на открытый фал сам "дропнится", либо воспользоваться функций drop напрямую. Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой.

Да, это косяк.

@korvin_ · 09.03.2021, 12:01

Сообщение от RatPoison

Если вы когда-нибудь имели дело с другими системными языками программирования, то наверняка заметили, что в Rust нет такой, казалось бы, простой и элементарной вещи, как функция закрывающая файл. Пользователям предлагается иметь дело либо с областями видимости и ждать, пока указатель на открытый фал сам "дропнится", либо воспользоваться функций drop напрямую. Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой.

А если вы ещё имели дело и с C++, D, Ada и Vala…

https://github.com/rust-lang/rust/issues/59567
https://github.com/rust-lang/rust/issues/32255

Сообщение от RatPoison

этот метод время кушает и бывает избыточен.

Однако только он гарантирует, что данные и метаданные были записаны. А close не гарантирует, и про «серьёзную ошибку игнорирования результата close» в https://linux.die.net/man/2/close написано как раз в контексте потери данных:

Not checking the return value when closing the file may lead to silent loss of data.
…
If you need to be sure that the data is physically stored use fsync(2)

@~~RatPoison~~ · 09.03.2021, 12:09 **[ТС]**

Сообщение от Vourhey

Да, это косяк.

ага

Сообщение от korvin_

Однако только он гарантирует, что данные и метаданные были записаны.

не обязательно при открытии файла читать данные всякий раз. может файл нужно открыть для чтения изначально. а уже потом, дальше в коде, для записи. Что тоже может привести к потере данных, если в первый раз файл не был закрыт.

@korvin_ · 09.03.2021, 12:16

Вот интересное чтиво про close: https://lwn.net/Articles/576478/

At one time many years ago there was a path in the kernel that returned an error from close and it broke so many things. Even emacs crashed.

The widespread overwhelming belief is that close() is just going to always succeed, and there is more harm than good from signalling errors at all from that function.

Добавлено через 2 минуты

Сообщение от RatPoison

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

Если файл только читается, то вызывать sync_all не нужно, очевидно же.

Сообщение от RatPoison

а уже потом, дальше в коде, для записи. Что тоже может привести к потере данных, если в первый раз файл не был закрыт.

Так после записи и вызывай sync_all, если хочешь убедиться, что всё записалось, в чём проблема?

@Curry Модератор 5106 / 3334 / 535 Регистрация: 01.06.2013 Сообщений: 6,999 Записей в блоге: 9
	09.03.2021, 00:48	15
	RatPoison, если хотите, поэкспериментируйте с sync_all, может быть его достаточно. 0

Vourhey Почетный модератор 7393 / 2639 / 281 Регистрация: 29.07.2006 Сообщений: 13,696
	09.03.2021, 11:31	17
	Сообщение от RatPoison Если вы когда-нибудь имели дело с другими системными языками программирования, то наверняка заметили, что в Rust нет такой, казалось бы, простой и элементарной вещи, как функция закрывающая файл. Пользователям предлагается иметь дело либо с областями видимости и ждать, пока указатель на открытый фал сам "дропнится", либо воспользоваться функций drop напрямую. Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой. Да, это косяк. 0

Новые блоги и статьи
Счётчик на базе сумматоров + регистров и генератора сигналов согласования. Hrethgir 07.01.2025 Создан с целью проверки скорости асинхронной логики: ранее описанного сумматора и предополагаемых fast регистров. Регистры созданы на базе ранее описанного, предполагаемого fast триггера. То-есть. . .	Как перейти с Options API на Composition API в Vue.js BasicMan 06.01.2025 Почему переход на Composition API актуален В мире современной веб-разработки фреймворк Vue. js продолжает эволюционировать, предлагая разработчикам все более совершенные инструменты для создания. . .	Архитектура современных процессоров inter-admin 06.01.2025 Процессор (центральный процессор, ЦП) является основным вычислительным устройством компьютера, которое выполняет обработку данных и управляет работой всех остальных компонентов системы. Архитектура. . .	История создания реляционной модели баз данных, правила Кодда Programming 06.01.2025 Предпосылки создания реляционной модели В конце 1960-х годов компьютерная индустрия столкнулась с серьезными проблемами в области управления данными. Существовавшие на тот момент модели данных -. . .	Полезные поделки на Arduino, которые можно сделать самому raxper 06.01.2025 Arduino как платформа для творчества Arduino представляет собой удивительную платформу для технического творчества, которая открывает безграничные возможности для создания уникальных проектов. Эта. . .	Подборка решений задач на Python IT_Exp 06.01.2025 Целью данной подборки является предоставление возможности ознакомиться с различными задачами и их решениями на Python, что может быть полезно как для начинающих, так и для опытных программистов. . . .
С чего начать программировать микроконтроллеры raxper 06.01.2025 Введение в мир микроконтроллеров Микроконтроллеры стали неотъемлемой частью современного мира, окружая нас повсюду: от простых бытовых приборов до сложных промышленных систем. Эти маленькие. . .	Из чего собрать игровой компьютер inter-admin 06.01.2025 Сборка игрового компьютера требует особого внимания к выбору комплектующих и их совместимости. Правильно собранный игровой ПК не только обеспечивает комфортный геймплей в современных играх, но и. . .	Обновление сайта www.historian.by Reglage 05.01.2025 Обещал подвести итоги 2024 года для сайта. Однако начну с того, что изменилось за неделю. Добавил краткий урок по последовательности действий при анализе вредоносных файлов и значительно улучшил урок. . .	Как использовать GraphQL в C# с HotChocolate Programming 05.01.2025 GraphQL — это современный подход к разработке API, который позволяет клиентам запрашивать только те данные, которые им необходимы. Это делает взаимодействие с API более гибким и эффективным по. . .	Модель полного двоичного сумматора с помощью логических операций (python) AlexSky-coder 04.01.2025 def binSum(x:list, y:list): s=^y] p=x and y for i in range(1,len(x)): s. append((x^y)^p) p=(x and y)or(p and (x or y)) return s x=list() y=list()	Это мы не проходили, это нам не задавали...(асихронный счётчик с управляющим сигналом зад Hrethgir 04.01.2025 Асинхронный счётчик на сумматорах (шестиразрядный по числу диодов на плате, но наверное разрядов будет больше - восемь или шестнадцать, а диоды на старшие), так как триггеры прошли тестирование и. . .

Vourhey Почетный модератор 7393 / 2639 / 281 Регистрация: 29.07.2006 Сообщений: 13,696
	04.03.2021, 13:41	2
	Сообщение от RatPoison Опять получим ошибку и панику. И это прекрасно. Жаль, что паника не в любом языке. Обрабатывай ошибки и говори о них пользователю. 0

@Curry Модератор 5106 / 3334 / 535 Регистрация: 01.06.2013 Сообщений: 6,999 Записей в блоге: 9
	04.03.2021, 16:25	3
	Сообщение от RatPoison Предлагаю в этой теме собирать, обсуждать и предлагаю решение тех проблем, которые язык Rust создаёт своим пользователям. Предлагаю для каждой проблемы создавать свою тему, как это обычно и делается на форумах. Добавлено через 1 минуту А ещё, кстати, предлагаю писать челобитную Микаэлю от нескольких человек чтобы он повелел прикрутить синтаксис rust-а к форуму. 0

@IamLost 88 / 108 / 6 Регистрация: 16.04.2019 Сообщений: 451 Записей в блоге: 4
	05.03.2021, 14:04	5
	Сообщение от RatPoison Но что если введенное число больше i32? А что если введённое число состоит из 10 тысяч знаков? Вы скажете такого не может быть? Я скажу что может, если число может быть больше 32бит, то что мне мешает ввести тысячи знаков? Сообщение от RatPoison Как быть? Парсить как самый большой тип, а потом приводить к нужному? Нет, разумно оценивать что ваша программа будет делать и с какими данными она будет работать? И если пользователь вздумал ввести число, которое больше чем 32бит сообщить ему об этом и попросить ввести корректные данные? Сообщение от RatPoison продолжение следует... Да, давайте дальше, так как это назвать проблемой языка можно разве с натяжкой. И вообще это разве проблема языка, а не проблема его стандартной библиотеки? 0

@IamLost 88 / 108 / 6 Регистрация: 16.04.2019 Сообщений: 451 Записей в блоге: 4
	05.03.2021, 16:19	7
	Сообщение от RatPoison Если для вас это не проблема, то давайте почитайте соседнюю тему о возможной уязвимости при чтении входных данных в строку или в вектор. А если вы из С пришли в Rust и хотите сделать что-то типа этого: Я тупой, я перечитал 3 раза и не понял в чём проблема. В том, что программа упадёт? В каком ЯП она не упадёт, если мы будем вводить строку действительно произвольной длины? Ввод же окончится после того как пользователь нажмёт Enter? Соотвественно в теории я могу ввести строку, в которой будет больше байт чем памяти компьютера. 0

@~~RatPoison~~ Заблокирован
	05.03.2021, 18:21 [ТС]	8
	Сообщение от IamLost Ввод же окончится после того как пользователь нажмёт Enter? Если говорить о методе read-line - то да. Точнее пока read-line не встретит символ новой строки - '\n', так как данные можно читать из любого потока - файл, tcp соединение и тд. Сообщение от IamLost В каком ЯП она не упадёт, если мы будем вводить строку действительно произвольной длины? Не знаю как в других языках, но от этого должна быть защита иначе это потенциальное место для возможных атак. Сообщение от IamLost Соотвественно в теории я могу ввести строку, в которой будет больше байт чем памяти компьютера. Ну всю память навряд ли удастся занять. Программа будет запрашивать у ОС память снова и снова, пока ОС не скажет: "Хватит". 1

@Curry Модератор 5106 / 3334 / 535 Регистрация: 01.06.2013 Сообщений: 6,999 Записей в блоге: 9
	05.03.2021, 19:25	9
	Сообщение от RatPoison Ну так библиотека реализована на возможностях языка. Если язык не предлагает других вариантов, то что едалть? Язык не позволяет написать свой крейт или найти подходящий? Сообщение от RatPoison данные можно читать из любого потока - файл, tcp соединение В 2021 не стоит обрабатывать большие данные через стандартные потоки. Сообщение от RatPoison от этого должна быть защита иначе это потенциальное место для возможных атак. Вам же написали - читайте в буфер. Сами же нашли from_utf8_lossy. А если посмотреть как она реализована, то увидим что там используется модуль lossy, к сожалению, пока экспериментальный. А так то можно им читать входной буфер пока там полные UTF-8 символы. А остаток оставлять пока получения следующих данных. 1

@~~RatPoison~~ Заблокирован
	08.03.2021, 19:36 [ТС]	10
	Если вы когда-нибудь имели дело с другими системными языками программирования, то наверняка заметили, что в Rust нет такой, казалось бы, простой и элементарной вещи, как функция закрывающая файл. Пользователям предлагается иметь дело либо с областями видимости и ждать, пока указатель на открытый фал сам "дропнится", либо воспользоваться функций drop напрямую. Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой. 0

@Curry Модератор 5106 / 3334 / 535 Регистрация: 01.06.2013 Сообщений: 6,999 Записей в блоге: 9
	08.03.2021, 21:05	11
	Сообщение от RatPoison Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой. А поискать? https://docs.rs/close-file/0.1.0/close_file/ 0

@~~RatPoison~~ Заблокирован
	08.03.2021, 21:10 [ТС]	12
	Сообщение от Curry А поискать? Отдельный крейт для этой функции? По-моему несерьезно. Эта функция должна быть в стандартной библиотеке. Интересно, она clib::fclose вызывает? 0

@Curry Модератор 5106 / 3334 / 535 Регистрация: 01.06.2013 Сообщений: 6,999 Записей в блоге: 9
	08.03.2021, 22:03	13
	Сообщение от RatPoison Отдельный крейт для этой функции? По-моему несерьезно. Эта функция должна быть в стандартной библиотеке. Ну, сырой rust по факту. "Всё равно его не брошу Потому что он хороший." (с) А. Барто. Ничего нет страшного, если крейт в зависимости добавить. Сообщение от RatPoison Интересно, она clib::fclose вызывает? Исходник посмотреть тоже никак? Для линя вызывает. Для винды kernel32::CloseHandle. 0

@~~RatPoison~~ Заблокирован
	08.03.2021, 22:53 [ТС]	14
	Сообщение от Curry Ничего нет страшного, если крейт в зависимости добавить. новичок не будет использовать сторонние крейты. он будет использовать стандартную библиотеку. Если Rust за безопасность, то это должно прослеживаться везде, а не быть просто на словах. Мы же хотим пользоваться хорошим языком ЯП. 0

@~~RatPoison~~ Заблокирован
	09.03.2021, 11:22 [ТС]	16
	Curry, да, я читал. этот метод время кушает и бывает избыточен. 0

@korvin_ 4542 / 2736 / 486 Регистрация: 28.04.2012 Сообщений: 8,647
	09.03.2021, 12:01	18
	Сообщение от RatPoison Если вы когда-нибудь имели дело с другими системными языками программирования, то наверняка заметили, что в Rust нет такой, казалось бы, простой и элементарной вещи, как функция закрывающая файл. Пользователям предлагается иметь дело либо с областями видимости и ждать, пока указатель на открытый фал сам "дропнится", либо воспользоваться функций drop напрямую. Однако при этом вы не сможете отловить ошибки, а возвращаемое значение при закрытии файла игнорируется, что является серьёзной ошибкой. А если вы ещё имели дело и с C++, D, Ada и Vala… https://github.com/rust-lang/rust/issues/59567 https://github.com/rust-lang/rust/issues/32255 Сообщение от RatPoison этот метод время кушает и бывает избыточен. Однако только он гарантирует, что данные и метаданные были записаны. А close не гарантирует, и про «серьёзную ошибку игнорирования результата close» в https://linux.die.net/man/2/close написано как раз в контексте потери данных: Not checking the return value when closing the file may lead to silent loss of data. … If you need to be sure that the data is physically stored use fsync(2) 0

@~~RatPoison~~ Заблокирован
	09.03.2021, 12:09 [ТС]	19
	Сообщение от Vourhey Да, это косяк. ага Сообщение от korvin_ Однако только он гарантирует, что данные и метаданные были записаны. не обязательно при открытии файла читать данные всякий раз. может файл нужно открыть для чтения изначально. а уже потом, дальше в коде, для записи. Что тоже может привести к потере данных, если в первый раз файл не был закрыт. 0

@korvin_ 4542 / 2736 / 486 Регистрация: 28.04.2012 Сообщений: 8,647
	09.03.2021, 12:16	20
	Вот интересное чтиво про close: https://lwn.net/Articles/576478/ At one time many years ago there was a path in the kernel that returned an error from close and it broke so many things. Even emacs crashed. The widespread overwhelming belief is that close() is just going to always succeed, and there is more harm than good from signalling errors at all from that function. Добавлено через 2 минуты Сообщение от RatPoison не обязательно при открытии файла читать данные всякий раз. может файл нужно открыть для чтения изначально. Если файл только читается, то вызывать sync_all не нужно, очевидно же. Сообщение от RatPoison а уже потом, дальше в коде, для записи. Что тоже может привести к потере данных, если в первый раз файл не был закрыт. Так после записи и вызывай sync_all, если хочешь убедиться, что всё записалось, в чём проблема? 0