From owner-freebsd-questions@freebsd.org Wed Jan 16 10:40:08 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA7521483234 for ; Wed, 16 Jan 2019 10:40:08 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from bede.qeng-ho.org (bede.qeng-ho.org [217.155.128.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50D16960DB for ; Wed, 16 Jan 2019 10:40:07 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from arthur.home.qeng-ho.org (arthur.home.qeng-ho.org [172.23.1.2]) by bede.qeng-ho.org (Postfix) with ESMTP id A0A5310640; Wed, 16 Jan 2019 10:39:54 +0000 (GMT) Subject: Re: libc : non-c specific functions! To: Polytropon , iam@sdf.org Cc: freebsd-questions@freebsd.org References: <201901160505.x0G558X1004475@sdf.org> <20190116111733.43ada98d.freebsd@edvax.de> From: Arthur Chance Message-ID: <635f935e-846f-39e7-c193-f952d4ecfd5b@qeng-ho.org> Date: Wed, 16 Jan 2019 10:39:54 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190116111733.43ada98d.freebsd@edvax.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 50D16960DB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd@qeng-ho.org designates 217.155.128.241 as permitted sender) smtp.mailfrom=freebsd@qeng-ho.org X-Spamd-Result: default: False [-3.28 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.956,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.155.128.240/29]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[qeng-ho.org]; NEURAL_HAM_LONG(-0.96)[-0.961,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mx1.mythic-beasts.com,mx2.mythic-beasts.com]; NEURAL_HAM_SHORT(-0.76)[-0.758,0]; SUBJECT_ENDS_EXCLAIM(0.00)[]; IP_SCORE(-0.30)[asn: 13037(-1.38), country: GB(-0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13037, ipnet:217.155.0.0/16, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 10:40:09 -0000 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 -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.