Why memory functions such as memset, memchr… are in string.h, but not in stdlib.h with another mem functions?

Question

I wonder, why such function as:
-memset
-memmov
-memchr
-memcpy

Exist in string.h header file, but not in stdlib.h file, where there are ot

Answer 1

I wouldn't really think of the string.h functions as "memory" functions. Instead, I would think of them as "array" functions, since they operate on the data which is contained within sequences of memory. By contrast, malloc (and others), actually provide memory services such as allocation, rather than manipulation of the data within a region of memory.

In particular, the functions in string.h do not take care of any allocation or deallocation of memory, or any form of memory management. Even a function like char * strerror(int), which appears to create a whole new string, does not do any allocations, because the return value is actually a statically-allocated string. The other functions might return a pointer to a memory block, but this is actually just one of their parameters (e.g. memcpy). Or they return a pointer to the start of a sub-string (strtok), or an integer representing a comparison (memcmp).

On the other hand, stdlib.h is also not really about memory. The design of stdlib.h is to provide general-purpose operations which a large number of program will likely need. The memory functions just happen to be examples of such fundamental operations. However, other functions like exit and system are also good examples, yet don't apply to memory.

Now there are some functions in stdlib.h which IMO could have been placed in string.h, particularly the various conversion functions (mbstowcs, wcstombs, atoi, strtod, etc.), and maybe even the bsearch and qsort functions. These functions follow the same principles as the string.h functions (they operate on arrays, don't return newly allocated memory blocks, etc).

But from a practical perspective, even if it made a lot of sense to combine the mem* functions with the malloc, realloc, calloc and free functions, the C standard library is never going to be reorganized like this. Such a change would definitely break code. Also, stdlib.h and string.h have been around for so long, and are both such useful and fundamental libraries, that the changes would probably break most (or at least, a lot of) C code.