4 ms·
As a corollary to writing the C standard library in Rust, are there any plans by the Rust devs to remove the C standard library dependency itself? That, to me,
by fpgaminer 10y ago
As a corollary to writing the C standard library in Rust, are there any plans by the Rust devs to remove the C standard library dependency itself? That, to me, is just as interesting of a proposition.
- steveklabnik 10y agoSo, with libcore, you don't have a libc dependency. With libstd, you do. There has been some interest in making it easier to port libstd away from it, but it would likely be a cross target, like musl itself, rather than an official move. We'll see what the future holds!
- pcwalton 10y agoIt's not a high priority task, no. (Though it would be quite interesting to see it done.) On Windows and Mac OS X you shouldn't really avoid C libraries (kernel32.dll and libSystem.dylib respectively) because the syscall interface is considered a private API. (You can avoid it technically, and apps sometimes do, but Microsoft and Apple would be within their rights to break us at any time if we did that.)
- ben0x539 10y agoOn Windows, does Rust currently require/use (nontrivial features of) the C standard library in addition to the C "win32"/"winapi"/w/e libraries?
- heinrich5991 10y agoThe math library AFAIK, in order to provide the same wrong results that the MSVC implementation gives.
- adrianratnapala 10y agoHeh? Can you point to a description of the wrongness of MSVC maths. I noticed that they were a bit slow to support infinities and NaN, but that is not the same thing a being wrong.
- melloc 10y agoIn addition to Windows and Mac OS X, illumos and I believe all of the BSDs require you to use libc for the same reason. I'm sure that they exist, but I don't know of any kernels other than Linux where the syscall layer is a stable interface. (I'd love to learn about some others though, if anyone knows.)
- pjmlp 10y agoBut those are technically the OS system calls, not libc. Would the Rust team accept PR to remove the dependencies on libc for Windows?
- masklinn 10y ago> But those are technically the OS system calls, not libc. They're libc calls, libSystem is the union of a bunch of libraries including libc. In fact, these unioned libraries are just symlinks to libSystem: libc.dylib -> libSystem.dylib libdbm.dylib -> libSystem.dylib libdl.dylib -> libSystem.dylib libgcc_s.1.dylib -> libSystem.B.dylib libinfo.dylib -> libSystem.dylib libm.dylib -> libSystem.dylib libmx.dylib -> libSystem.dylib libpoll.dylib -> libSystem.dylib libproc.dylib -> libSystem.dylib libpthread.dylib -> libSystem.dylib librpcsvc.dylib -> libSystem.dylib
- pjmlp 10y agoStill, isn't ironic that a systems programming language isn't able to be used without C, because its runtime was made to rely on libc instead of the raw OS APIs? I understand the shortcut as a way to reduce development time, but maybe that is something to improve. Go made the right decision by integrating directly with the OS APIs.
- claudius 10y ago> rely on libc instead of the raw OS APIs? The argument here is that on Windows and Mac OS X, the libc library is the ‘raw OS API’ and it hence makes perfect sense to rely on it if you want to support such operating systems.
- pjmlp 10y agoIf I want to zero memory on Windows without libc dependencies, I use ZeroMemory() or FillMemory() and not memset(). No need to have any dependency on msvcr*.dll or the equivalent for Borland, Intel and other Windows compilers, which are effectively the Windows libc.