It would certainly be possible to implement malloc and free as system calls, but it's rarely if ever done that way.

System calls are calls into the OS kernel. For example, on POSIX systems (Linux, UNIX, ...), read and write are system calls. When a C program calls read, it's probably calling a wrapper that does whatever is needed to make a request to the kernel and then return the result to the caller.

It turns out that the most efficient way to do memory management is to use lower-level system calls (see brk and sbrk) to expand the current process's data segment, and then use library calls (malloc, free, etc.) to manage memory within that segment. That management doesn't require any interaction with the kernel; it's all just pointer manipulation performed within the current process. The malloc function will invoke a system call such as brk or sbrk if it needs more memory than is currently available, but many malloc calls won't require any interaction with the kernel at all.

The above is fairly specific to Linux/POSIX/UNIX systems. The details will be a bit different for Windows for example, but the overall design is likely to be similar.

Note that some C standard library functions are typically implemented directly as system calls. time is one example (but as Nick ODell points out in a comment, a time call can often be performed without interacting with the kernel).

It seems like the OS is responsible for handling all memory allocation requests.

Well, both yes and no

It actually depends more on your specific system than it depend on C.

Most OS allocates memory in trunks of some size. Typically called a page. The page size may differ. And on a specific system there may be several supported page-sizes. 4K is a typical page-size on many systems but huge page much bigger may be supported.

But yes... at the end of the day there is only one entity that can allocate memory. The OS. Unless you are on bare-metal where other code can handle it - if even supported.

Why is malloc() considered a standard C library function and not a system call?

The short answer is: Because malloc isn't a OS/systemcall. Period.

To elaborate a bit more. One malloc call may lead to a systemcall but the next malloc may not.

For instance: You request 100 bytes using malloc. malloc may decide to call the OS. The OS gives you 4K. In your next malloc you request 500 byte. Then the "layer in between" can just give the 500 bytes from the trunk already provided by the previous syscall.

So no... memory allocation via malloc may not lead to any syscall for alocation of more memory.

It's all very dependent on your specific system. And the C standard doesn't care.

But malloc is not a syscall. malloc uses other syscalls when needed.

It seems like the OS is responsible for handling all memory allocation requests.

For performance reasons, it's not a good idea to ask the OS for memory every time the program needs memory. There are a few reasons for this:

1. The OS manages memory in units called pages. Pages are typically 4096 bytes long. (But some architectures or operating systems use larger pages.) The OS can't allocate memory to a process in a chunk smaller than a page.

   Imagine you need 10 bytes to store a string. It would be very wasteful to allocate 4096 bytes and only use the first 10. A memory allocator can ask the OS for a page, and slice that page into smaller allocations.

2. A system call requires a context switch. A context switch is expensive, (~100 ns on x86 systems) relative to calling a function in the same program. Again, it is better to ask for a larger chunk of memory, and re-use it for many allocations.

Why is malloc() considered a library call and not a system call?

For some library calls, like read() the implementation in the library is very simple: it calls the system call of the same name. One call to the library function read() produces one system call to read(). It's reasonable to describe read() as a system call, because all the work is being done in the kernel.

The story with malloc() is more complicated. There's no system call called malloc(), and the library call malloc() will actually use the system calls sbrk(), brk(), or mmap(), depending on the size of your allocation and the implementation you're using. Much of the time, it makes no system call at all!

There are many different choices in how to implement malloc(). For that reason, you'll see many different competing implementations, such as jemalloc, or tcmalloc.