Open Roger opened 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
Hey, so I just stumbled upon this project and felt like I might as well answer some of these.
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).clap
, getopts
, etc. This is indeed an issue that I am in the midst of fixing (everything is migrating to clap
or structopt
. Unfortunately, some utilities still require manual argument parsing, and there's not really much that I can do about thatlibc
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.* `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.
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