brk and sbrk are system calls (implemented in the kernel) while malloc, free, realloc are library functions in user space. So the malloc etc functions use brk and sbrk internally but provide additional functionality (see man(2) for more details about brk and man(3) for more details about malloc.).

brk only tells the kernel how much memory your program wants to use, by giving the the kernel a pointer to the largest virtual memory location that your program may use. But you only have exactly one big chunk of memory.

malloc helps you to subdivide this huge block of memory into smaller parts.

Example code doesn't make much sense here, because brk and malloc work on different levels. But you could think how you would implement a very simple (and non-thread-safe) version of malloc and free and where you would use brk there:

1. The basic data structure for our primitive malloc is a linked list.
2. Each list element in the list contains of:
   1. The size of the block
   2. A pointer to the next element
   3. A flag if the block is in use
   4. A flag if it is the last element
   5. An array of bytes with the given size
3. In each call, malloc goes through the list and checks for each block
   1. If the block is flagged as "not in use"
   2. If the size field of the list element is at most as big as the size needed
4. If malloc finds such a block, it will:
   1. Mark the list element as used
   2. Adjust the size field in the list element
   3. If there is enough space then add a list element after the element, pointing to the next element in the list (if applicable)
   4. Return a pointer to the byte array of the list element it found
5. If malloc doesn't find such a list element, it will
   1. Call brk to increase the usable memory we got from the kernel
   2. Add a new element to the end of the list, set the size to the desired size
   3. Mark this element as in use AND as the last element
   4. Return a pointer to the byte array of the newly created list entry

And as @BasileStarynkevitch remarked in his comment, as an alternative to brk you could also use mmap (with fd=-1 and flags=MAP_PRIVATE|MAP_ANONYMOUS) to reserve a single block of memory backed by the swap file. For details about mmap see man(2).

At the OS level (in the Unix model, at least), your program has one big region of memory for program text, initialized and uninitialized data, and the "heap", for dynamically-allocated data. (The stack is separate.) You can adjust the size of that region using brk and sbrk, but you can't rearrange it, and it's always contiguous. The vast majority of programs that do dynamic memory allocation require something more flexible.

malloc, free, and realloc are C library functions that give you something more flexible. Underneath, they get memory from the OS by calling brk and/or sbrk, but then they do extra processing to let you allocate (a) any number of chunks of (b) different sizes and which you can (c) individually return to the pool when you're done with them and incidentally (d) resize.

But when you return memory to the pool with free, it generally just goes back into the pool that future calls to malloc by your program will draw from; memory is generally not given back to the OS.

(Sorry for not providing any example code; I don't have time for that just now.)