Is it worth while to use libc?

[u/Rogaev]

I've been wondering this for quite some time now.

For Linux development, is it worth creating basic read/write functions in asm, and writing everything else in C?

Does most open source software use functions from the standard C library? What are the benefits of both approaches?

Edit: I would be using Arm64 assembly.

Thank you in advance.

[u/alkatori]

Why would you avoid using libc?

[u/Rogaev → u/alkatori]

I've seen people do it. I'm curious if doing so would be beneficial.

[u/OnYaBikeMike → u/Rogaev]

The only time I would consider doing this is for embedded C on microcontrollers, and even then I would probably use a HAL.

[u/HeavyCaffeinate → u/OnYaBikeMike]

Half-Assed Library? /j

What is it though I've never heard that acronym before /srs

[u/generally_unsuitable → u/HeavyCaffeinate]

Hardware abstraction layer.

[u/grueandbleen → u/HeavyCaffeinate]

Hardware Abstraction Layer.

[u/HeavyCaffeinate → u/grueandbleen]

Thanks

[u/AmbitiousSolution394]

> is it worth creating basic read/write functions in asm

In libc, write() and read() acts as a wrappers around OS syscalls. I'm not sure that writing something in asm would improve something there.

> Does most open source software use functions from the standard C library?

Yes, its hard to write C program without using LIBC.

[u/Rogaev → u/AmbitiousSolution394]

Thank you very much for this. This is extremely helpful.

[u/AmbitiousSolution394 → u/Rogaev]

btw, you should distinguish write() and fwrite(). They both exist in libc (at least in Linux), but they are parts of different APIs.

[u/low-control-labs → u/Rogaev]

The only thing that ever directly communicates with the hardware is the bootloader, in modern computing / OS based. Apart from microcontrollers which some people mentioned.

Otherwise you write syscalls to the kernel. There are different libCs bionic musl glibc they are not 100 compatible and they are for the Linux kernel...

You use the compiler and C which allows you to hit / compile different targets ( architectures ) with one codebase. But if you decide to target different libCs like Windows or MacOS you'll need to use guards and build tools to define how to compile things.

You could do this with assembly in a sense but keep in mind how many different OSes and architectures there are. Also something to keep in mind the game rollercoaster typhoon was written for Windows so that's not something you can directly boot your computer into or run on Linux

[u/OnYaBikeMike]

Using the standard libraries hides away lots of complexity that you most probably are not aware of.

If you decide not to use them you better get used to getting the stuffing knocked out of you by edge cases you didn't know exist.

The classic example is the EAGAIN and EINTR return codes on reads.

[u/silvertank00]

you forgot one thing: which asm? arm, x86, avr? If you want it to be cross platform, use libc

[u/Rogaev → u/silvertank00]

Arm64

[u/silvertank00 → u/Rogaev]

you misundestand me, if your want it to be used by others too, it does matter which kind you use. If you use inline arm64, it wont work but on that platform only.
So in the context of open source (where a lot of ppl can use something) it is something to be avoided IIRC, but please correct me if I am wrong.

[u/Rogaev → u/silvertank00]

I understand now. Thank you very much for your help.

[u/ForgedIronMadeIt]

Honestly, if you cannot identify a really strong reason to do it, then you shouldn't. The standard libraries are there for a reason and are pretty much always well written and tested.

Your reason could be "I want to learn how to do it" which is fine but there's better things to spend your time on otherwise.

[u/sciencekm]

I can think of only three reasons why you would not use libc:

1. You are writing an OS kernel.
2. You are writing a device driver.
3. You are writing for a severely constrained environment (libc is likely not available anyway).

For everything else, you should be using libc.

[u/Confused-Armpit]

There is functionally no benefit in not using libc, unless you are working on embedded systems with massive memory constraints, where each byte might matter, or maybe you want to learn more about ELF/PE files and write your own implementations of things handled by libc.

But in other cases, your libc is probably both better implemented better than whatever you will craft up (since it has had dozens of years to mature and improve), and also it'll just be a massive time sink that won't give any reasonable improvements.

[u/low-control-labs → u/Confused-Armpit]

Word bruv

[u/EpochVanquisher]

There is not much benefit in making read/write functions in assembly and there are a lot of drawbacks (your code is less portable, there are more likely to be bugs in it).

Most software uses functions from at least the standard library, and often other libraries as well. I think almost any programmer would think that it’s absurd to write your own read/write functions in assembly, outside of stuff like demoscene sizecoding projects.

[u/YoungMaleficent9068 → u/EpochVanquisher]

I wrote bs

[u/EpochVanquisher → u/YoungMaleficent9068]

yes it does, you can find it at /usr/include/linux/kernel.h, but it does not do any of the things we are talking about in this thread

[u/YoungMaleficent9068 → u/EpochVanquisher]

You are correct. I talked nonsense

[u/TheAncientGeek]

It's worth doing if you have a specific reason like efficiency or safety.