libc : non-c specific functions!

[Arthur Chance]

On 16/01/2019 10:17, Polytropon wrote:
> On Wed, 16 Jan 2019 05:05:08 GMT, iam at 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.