Hacker News new | past | comments | ask | show | jobs | submit login

Well, I don't see that the "metadata" are actually obtained from the opened file handle in the Rust version?

Metadata request must happen at the different time point than the open of the file and the API as far as I see works on the path, not on the handle:

https://doc.rust-lang.org/std/fs/fn.metadata.html

which says to me that the Rust version can manifest the bug of the same kind -- there are different time points in which different independent information is checked, and that all the calls correspond to the same opened file handle just can't be assured?

As far as I understand only checking the properties of the opened file via the same file handle is safe for the described kind of bugs, nothing else.




> Metadata request must happen at the different time point than the open of the file and the API as far as I see works on the path, not on the handle

std::fs::File::metadata operates on the open file. If the file is replaced with something else, your open file handle will still refer to the (orphaned) file, and the metadata still reflects its properties.


Then, if C++ could also obtain metadata using the file handle, and the Rust programmer must also take care to call the right "metadata" which even when it does different thing is named completely the same and as the code as written doesn't make obvious if the right overloaded metadata is called, how is Rust better? I.e. how Rust in this example helps me as a reader of the code to be sure if the right metadata function was called?

Call me old fashioned, but only C is more sure to be explicit there as it wouldn't allow two different functions having the same name. If in C++ the corresponding names are also overloaded, both C and C++ "aren't cutting" if the obviousness is not there.


I never claimed that Rust was better in this regard, I merely pointed out that getting metadata from a path is not the only way.

Filesystem handling is not trivial, and some knowledge is required beyond the language itself. I do think that File::metadata and Path::metadata make a nice API together (better than lstat, stat, and fstat).

As for C not allowing two functions with the same name, sure, but then it doesn't have namespaces. In a nicely designed C library for file handling, these functions might well be called std_path_metadata and std_file_metadata, which boils down to the same thing.


You haven't answered my question? How I as a reader see which of the functions with different semantic but named the same was used in the Rust version, and how Rust helps me for that?


Ah right. I misunderstood your question.

No, Rust won't help you with that. On the contrary, Rust has excellent type inference, and in this case the name belongs to a type, which itself is inferred. As a casual reader, you'd have to track the documentation on the preceding calls.


That‘s not different from C++ however.


You can get it from a File too: https://doc.rust-lang.org/std/fs/struct.File.html#method.met...

(This doesn’t invalidate your point, of course, just saying you can do this.)


The rust code gets the metadata from the opened file handle, which internally uses fstat (on Unix).

it would have been just as possible to write the code incorrectly by using the path version to get metadata.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: