Naming of this crate / repository

[ian-h-chamberlain]

There's a few names rolling around in this crate at the moment:

• rust-linker-fix-3ds is the name of the repo, which is a bit long
• linker-fix-3ds is the name of the Cargo package (what would go on https://crates.io)
• linker_fix_3ds is the name of the crate, although this doesn't matter much since most consumers would never use it directly (except maybe as extern crate)

I think it would be good to be consistent and use the same name everywhere. We already have a convention of using - rather than _ for these crates, so I think we should probably stick with that. Some options:

• Simply linker-fix-3ds for https://crates.io as well as the repo name. This is the least amount of change from what we have
• libc-3ds. I think this describes what the crate does reasonably well (fills out missing libc APIs) and is nice and short but easily searchable. Doesn't exist yet: https://crates.io/search?q=libc-3ds
  • libc-3ds-rs maybe if we want to make it super obviously Rust, but I think being in the rust3ds org is probably good enough to make that clear
• ??? Open to other options

[Meziu]

You reminded me of this comment from @AzureMarker.

I really like the “polyfill” name (and it’s also coherent with the definition), so I suggest “polyfill-3ds”.

I must’ve woke up weird the morning of the day I named this repo “rust-linker-fix-3ds”, because I literally cannot think of a worse (yet somehow coherent) name. 😂

[ian-h-chamberlain]

Hmm, polyfill does seem to describe sort of what this crate does, and would be familiar to those who have experience with web dev. Wikipedia seems to indicate this is almost exclusively used to refer to web browsers though, so I'm not sure if that would be a common way to use it.

I think including libc in the name might also be good, since this crate is providing C standard library functions to supplement missing stuff from newlib. I found some articles about doing this type of thing for other platforms but they don't seem to have a specific name for the kind of thing we are doing:

• https://interrupt.memfault.com/blog/boostrapping-libc-with-newlib
• https://wiki.osdev.org/Creating_a_C_Library

So far I haven't been able to find too many other crates doing something similar, although here are two examples of a full-blown libc implementation in Rust:

• https://github.com/sunfishcode/mustang/tree/main/c-gull
• https://gitlab.redox-os.org/redox-os/relibc/

I don't have too strong of an opinion here, especially since this crate is likely to stay pretty small and not change a lot. Lmk what you think.

[Meziu]

I would like to avoid the "libc" nomenclature mainly to avoid misleading the end user. One thing is to call this crate a mere "polyfill", another is to call it a "libc implementation". If it were for me this crate would disappear entirely, but it does serve a purpose, which is NOT to be used directly.

For example, I've already seen people discuss pthread-3ds as a "complete implementation", because the name gives away a sense of completeness. From this point of view, rust-linker-fix-3ds is such a bad name people would stay away from using it, which is kind of what we want.

At the end of the day the name is just a form of communication, and for these crates that is a delicate topic. "polyfill" is not the only option (and probably not the best) but, as always, anyone can make other suggestions.

[ian-h-chamberlain]

For example, I've already seen people discuss pthread-3ds as a "complete implementation", because the name gives away a sense of completeness. From this point of view, rust-linker-fix-3ds is such a bad name people would stay away from using it, which is kind of what we want.

That's a fair point, I can see the reasoning behind wanting to make sure people don't expect too much out of this crate (perhaps a good README would help with that).

The wikipedia article references this StackOverflow which mostly seems to suggest that "shim" is a slightly more general term that we could use.

In particular I like this description:

A shim is a library that brings a new API to an older environment, using only the means of that environment.

What do you think about these?

• shim-3ds
• std-3ds-shim
• libc-shim-3ds (maybe not for the reasons you already described)
• something else?

[Meziu]

I'd go with shim-3ds, tell me if you think it could be definitive 👍

[ian-h-chamberlain]

works for me! We can see if anyone else from @rust3ds/active has opinions but I think that plus a small README explaining the purpose of the crate sounds fine

[Meziu]

Opened the PRs to do the job:

• [x] #21
• [x] https://github.com/rust3ds/ctru-rs/pull/114

I'll need to rename the repo before merging the changes in ctru-rs

[Meziu]

I've renamed the repo and the package. No issues downstream 👍