Post #3556443

2026-07-03 12:53 UTC

Well, if you want to be pedantic, I’ll entertain you a bit more. You see, C and Unix were “born” together. So sometimes, POSIX intertwines them in weird ways. In this case, getlogin is declared in unistd.h because it’s part of the Unix standard API, however the POSIX standard states that it must be implemented in libc. So the POSIX compliant way to getlogin is to call into libc, which doesn’t need to be glibc, you could use musl and avoid the GNU dependencies. If rust’s stdlib were to offer a getlogin function, the proper approach would be to still call libc. It’s like if on windows you were to call into Win32 to getuser, except on *nix it’s the same file as libc. If you want to replace the getlogin implementation, the POSIX compliant place to do it is not in coreutils but in libc, like the aforementioned musl library does. So the key here is that getlogin is not art of the c system API. It is actually part of the POSIX APIs, it is just “located” inside of libc, which by the way, does not need to be GNU if you are concerned with uutils’ philosophy.

Replies (1)

@cockmushroom@reddthat.com 2026-07-03 14:52

I don’t think I do want to be pedantic but, to be explicitly clear, the philosphy I’m associating with uutils is capured by the “rewritie it in rust” mantra, so whether or not their posix compliant interface uses GNU code is beside the point. More importantly, if their goal was a posix compliant api, then I’d have assumed they would have included that in their repo description, or even called the project posix.rs; but they didn’t. What’s more is that the rust standard library isn’t equivalent to that of C, so it would still make sense that for a project whose goal was, or has simply become, to replace a C codebase would offer a safe C alternative to its dependencies. But maybe that’s their next step; an internal library offering enough of a posix api to avoid surprises like these.

Open ##3558205