GrayJack / coreutils

Core utils re-implementation for UNIX/UNIX-like systems written in Rust
Mozilla Public License 2.0
108 stars 40 forks source link

What's the problem with uutils? #62

Open Roger opened 5 years ago

Roger commented 5 years ago

This is not a complain, I just want to understand the reason behind this project, since another trying to do the something similar exists, I understand the part that this don't try to be 100% compatible with coreutils (maybe making this easier to implement?), so would be cool to have the goals a bit more explained in the README

GrayJack commented 5 years ago

For me, and that's my take on this matter, there are 4 things

The last one, I see several people doing this, but I consider a anti-patterns that I would like to avoid.

I'll try to put in better words on the README as goals

Arcterus commented 4 years ago

Hey, so I just stumbled upon this project and felt like I might as well answer some of these.

GrayJack commented 4 years ago
* `uumain` exists so that there is a unified entrypoint to each utility.  This allows the multicall binary (named `coreutils` currently, but formerly it was called `uutils`) to use the exact same code for a utility as when you compile the utility individually (_e.g._ you want a `cp` binary, not a symlink named `cp` that points to the `coreutils` binary).

I see, like busybox, right?

* Ideally the utilities would work everywhere, but obviously more focus is put on platforms that the maintainers and users actually use (hence the focus on Windows beyond just Unix-like platforms)

Yeah, I agree, I mostly use Linux, FreeBSD and also NetBSD in some degree, so I decided to focus mostly on UNIX, but I don't have problems supporting Windows as well, I just don't use it and have no knowledge about the Windows API to do the same for every utility. Haiku is there because I do have a crazy friend that loves haiku and was interest in trying the project in that OS. Fuchsia was just a test since it's a tier2 target and I could easily check the code if it compiles or not.

* I think you are referring to using a newtype to hold a pointer to a `libc` `struct`?  Doing so seems safer to me than reimplementing everything as you don't really need to worry about new fields being added as you are just using the underlying C `struct`.  If you reimplement everything and aren't careful, you could assume the `struct` is some specific size, end up being wrong, and then cause a buffer overflow.  This, of course, assumes I'm correctly interpreting what you mean.

Now that's a interesting subject cause I have a different opinion compared to Sep 2019. I do not consider that a anti-pattern anymore.

What I was talking about is creating a new high level struct with all new fields using a more rusty types, but with a condition, it cannot be used as is in C call that would require the C version of the struct, till now I just got utilities that don't write into those structures, so the idea was just have new struct holding the data in a easier to use rust types just to look at the data and print it in a way. I still think that this is a better approach for the sole purpose is to read data in a easy way, but now I don't consider the raw pointer in the inner of the struct a bad idea.

Even before I thought that if you mainly need to either to change data inside and/or keep passing the C struct back and forth to C calls and/or depend of the size of the struct, inner field with the C struct is the way to go, for the same reasons you mentioned, and now I do think recreating the struct in rust a anti-pattern, always.