Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fs::list_dir should only return the contents of the directory #1919

Closed
jsternberg opened this issue Mar 2, 2012 · 6 comments
Closed

fs::list_dir should only return the contents of the directory #1919

jsternberg opened this issue Mar 2, 2012 · 6 comments
Assignees

Comments

@jsternberg
Copy link
Contributor

Currently using fs::list_dir will append the directory name to the front of every entry. I think fs::list_dir should only return the contents of the directory, and maybe another utility function should use fs::list_dir to give the current behavior.

The only other way I can see to access the contents of a directory is with os_fs::list_dir, but that seems like it's not supposed to be public. A comment in the source code has:

// FIXME: generic_os and os_fs shouldn't be exported
export generic_os, os, os_fs;
@ghost ghost assigned brson Mar 8, 2012
@catamorphism
Copy link
Contributor

I'm not sure how to determine what the correct behavior is. Is fs::list_dir supposed to implement some standard Unix API? I'm assuming it works the way it does for a reason.

Assigning to @brson since he seems to have touched this code.

@jsternberg
Copy link
Contributor Author

The main issue is that there doesn't seem to be an easy way to get a directory listing without accidentally prepending the current directory to every entry returned. So currently, if I want to find the entries in a directory, I need to use fs::list_dir then slice off the section of the string dealing with the current directory. It's much easier to join two paths than it is to remove a path.

If I don't want to go about modifying the string that many times (fs::list_dir goes out of its way to prepend the directory name), my only current choice is to start messing around with opendir and readdir in native code. To do something as simple as listing a directory, I really shouldn't have to start messing around with pointers and unsafe code.

@brson
Copy link
Contributor

brson commented Mar 9, 2012

I do appear to have touched this code as I wrote the only bit of code that actually uses it. I don't remember why it behaves the way it does - probably because that is the exact functionality that rustc needed at the time - but let's change it to do the more intuitive thing. @jsternberg are you interested in making the change?

@brson
Copy link
Contributor

brson commented Mar 9, 2012

Oh, cargo uses it more than rustc, so clearly there's a good use case for the current behavior. Maybe we should split it into two functions, or at least make sure there's an easy one-liner to get the current behavior.

@jsternberg
Copy link
Contributor Author

Yea, I can make the change at some point this weekend. If cargo is the only thing that uses it, I'll change that too.

@brson
Copy link
Contributor

brson commented Apr 1, 2012

Fixed by 3a0477c. Thanks @jsternberg

@brson brson closed this as completed Apr 1, 2012
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
- Change `#[kani::proof]` expansion so it doesn't include `#[no_mangle]` but includes `[allow(dead_code)]`. (rust-lang#661 and rust-lang#689).

- Add a check for harnesses with arguments and merge the checks into one function (rust-lang#1919). 

Co-authored-by: Zyad Hassan <88045115+zhassan-aws@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants