Date: Wed, 16 Jan 2019 10:39:54 +0000 From: Arthur Chance <freebsd@qeng-ho.org> To: Polytropon <freebsd@edvax.de>, iam@sdf.org Cc: freebsd-questions@freebsd.org Subject: Re: libc : non-c specific functions! Message-ID: <635f935e-846f-39e7-c193-f952d4ecfd5b@qeng-ho.org> In-Reply-To: <20190116111733.43ada98d.freebsd@edvax.de> References: <201901160505.x0G558X1004475@sdf.org> <20190116111733.43ada98d.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/01/2019 10:17, Polytropon wrote: > On Wed, 16 Jan 2019 05:05:08 GMT, iam@sdf.org wrote: >> is there any way to find out which functions in libc are non-c >> specific, so for example if i had to implement a syslib in >> assembly language, i could just avoid the "c" parts as they >> would be irrelevant. > > Everything that's in the standard C library is stuff required > by the C standard. It doesn't actually matter _how_ it is > implemented, even though it's commonly implemented in C. > So "nothing and everything is C-specific". ;-) > > Your question is a bit strange (or I'm just too stupid to > understand it correctly). > > Allow me to explain: > > The libc isn't there for its own good. It's a library used > by other programs which call functions from that library > using those function names, after linking to that library, > simplified speaking. If you would implement your alternative > system library, let's say libsys, and let's say you do this > in assembly, then no other program could use it _except_ you > implement the calling interface (i. e., its API) in the > exact same way. This is the only way other programs could > use it instead of libc. > > Example: You want a non-libc equivalent of dmesg. You start > by examining /usr/src/sbin/dmesg/dmesg.c, which header files > does it include? Which libc calls does it make? Your libsys > would heed to implement them - _how_ it does that is of no > interest to the compiler / linker. So after you've done that, > you could recompile "cc -lsys <more stuff> -o dmesg dmesg.c" > and it would no longer need libc. > > On the other hand, if you're going to develop your own (!) > userland tools, based upon your own libsys written in assembly, > you can create your own new universe, as long as compatibility > is not required. > > FreeBSD's implementation of libc is in /usr/src/lib/libc and > its subdirectories. Even though the standard C library is a > very common thing, it's implemented differently on the many > existing operating systems, and even its name can be different, > for example glibc (GNU libc) on Linux. The content can also > be different, as the C standard requires certain things, but > the library maintainer could decide to add other things, for > example POSIX extensions (which are not required by the C > standard). If you wish to "compare and contrast" you could also take a look at the musl libc and see the differing trade-offs that makes Wikipedia entry: https://en.wikipedia.org/wiki/Musl The musl web site: https://www.musl-libc.org/ It even has a "See how musl compares to other major libcs" link.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?635f935e-846f-39e7-c193-f952d4ecfd5b>