memset、memchr ...などのメモリ関数がstring.hにあるのに、stdlib.hに別のmem関数があるのはなぜですか？
なぜこんな機能があるのだろうか？
-memset
-memmov
-memchr
-memcpy
String.hヘッダーファイルには存在しますが、stdlib.hファイルには存在しません。stdlib.hファイルには、動的メモリ割り当てとして他の標準メモリ関数があります：malloc、calloc、realloc、free。
たぶん、それらを1つのヘッダーに統合する方が良いでしょうか？あなたはそれについてどう思いますか？メモリ関数の1つのセットが他のメモリ関数から分離され、文字列ヘッダー（string.h）に存在する理由はわかりません。
実際にstring.hは、文字列だけでなく文字の配列を扱う関数を宣言する標準ヘッダーとして定義されています。 memcpyやmemsetなどの関数は、文字の配列型のオブジェクトの最初の要素へのポインターとして扱われる引数を取ります。
（C99、7.21.1p1）ヘッダー<string.h>は、1つの型と複数の関数を宣言し、文字型の配列および文字型の配列として扱われる他のオブジェクトの操作に役立つ1つのマクロを定義します。
_string.h_関数を「メモリ」関数とは本当に思わないでしょう。代わりに、メモリのシーケンス内に含まれるデータを操作するため、「配列」関数と考えます。対照的に、malloc（およびその他）は、実際にはメモリ領域内のデータの操作ではなく、割り当てなどのメモリサービスを提供します。
特に、_string.h_の関数は、メモリの割り当てや割り当て解除、またはメモリ管理の形式を考慮しません。 char * strerror(int)のような関数は、まったく新しい文字列を作成するように見えますが、実際には戻り値は静的に割り当てられた文字列であるため、割り当てを行いません。他の関数はメモリブロックへのポインターを返す場合がありますが、これは実際にはパラメーターの1つにすぎません（例：memcpy）。または、サブストリングの先頭へのポインター（strtok）、または比較を表す整数（memcmp）を返します。
一方、_stdlib.h_は実際にはメモリに関するものでもありません。 _stdlib.h_の設計は、多数のプログラムが必要とする可能性が高い汎用操作を提供することです。メモリ機能は、たまたまそのような基本的な操作の例です。ただし、exitやsystemなどの他の関数も良い例ですが、メモリには適用されません。
現在、stdlib.h_にはIMOを_string.h_に配置できる関数がいくつかあります。特に、さまざまな変換関数（mbstowcs、wcstombs、atoi 、strtodなど）、場合によってはbsearchおよびqsort関数も含まれます。これらの関数は_string.h_関数と同じ原則に従います（それらは配列で動作し、新しく割り当てられたメモリブロックを返しませんなど）。
しかし、実際の観点からは、_mem*_関数とmalloc、realloc、calloc、free関数、C標準ライブラリはneverのように再編成されます。そのような変更は間違いなくコードを壊します。また、_stdlib.h_と_string.h_は非常に長い間存在しており、非常に有用かつ基本的なライブラリであるため、変更によっておそらくほとんどの（または少なくとも多くの）Cコードが壊れる可能性があります。
プレスタンダードCでは、これらの関数は実際に別の場所で定義されていましたが、stdlib.hや他の標準ヘッダーではなく、memory.hで定義されていました。システムにまだ存在している可能性がありますが、OS Xには確かに存在します（現在）。
memory.h OS X 10.11の場合（ライセンスヘッダーなし）：
#include <string.h>
ファイル全体は#include 'ing string.hのみであり、先行標準Cプログラムとの後方互換性を保持します。
歴史的な考慮事項に加えて、string.hのようなデータ操作ユーティリティとstdlib.hのmallocのようなシステム関数の分離は、オペレーティングシステムが与えられた。組み込みシステムには、RTOSがある場合とない場合があります。また、標準メモリ割り当てを使用できる場合とない場合があります。ただし、strcpyやmemcpyなどのユーティリティは同様の外部システムに依存しないため、コンパイルされたコードを実行できる任意のコンテキストで実行できます。概念的および実際的には、それらをまとめて、より複雑なシステムコールから分離するのが理にかなっています。