Почему функции памяти, такие как memset, memchr ... находятся в string.h, а не в stdlib.h с другими функциями mem?

Question

Интересно, почему такая функция как:
-мемсет
-мемов
-memchr
-memcpy

Существует в заголовочном файле string.h, но не в файле stdlib.h, где есть другие стандартные функции памяти, такие как динамическое выделение памяти: malloc, calloc, realloc, free.

Может быть, было бы лучше объединить их в один заголовок? Что вы думаете об этом? Я не понимаю, почему один набор функций памяти отделен от других и существует в строковом заголовке (string.h).

Answer 1

Потому что на самом деле string.h определяется как стандартный заголовок, который объявляет функции, которые обрабатывают массив символов, а не только строки.Такие функции, как memcpy и memset, принимают аргументы, которые обрабатываются как указатели на первый элемент объекта типа массив символов.

(C99, 7.21.1p1) Заголовок <строка.h> объявляет один тип и несколько функций и определяет один макрос, полезный для манипулирования массивами символьного типа и другими объектами, обрабатываемыми как массивы символьного типа.

Answer 2

Я бы не думал, что функции string.h являются функциями "памяти". Вместо этого я думал бы о них как о функциях «массива», поскольку они работают с данными, содержащимися в последовательностях памяти. Напротив, malloc (и другие) фактически предоставляют услуги памяти, такие как выделение, а не манипулирование данными в области памяти.

В частности, функции в string.h не заботятся о каком-либо выделении или освобождении памяти или какой-либо форме управления памятью. Даже такая функция, как char * strerror(int), которая, кажется, создает целую новую строку, не выполняет никаких выделений, потому что возвращаемое значение на самом деле является статически размещаемой строкой. Другие функции могут возвращать указатель на блок памяти, но на самом деле это только один из их параметров (например, 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 равна никогда не будет так реорганизован. Такое изменение определенно нарушит код. Кроме того, stdlib.h и string.h существуют уже так давно и являются настолько полезными и фундаментальными библиотеками, что изменения, вероятно, нарушат большую часть (или, по крайней мере, большую часть) кода C.

Answer 3

В Pre-Standard C эти функции действительно были определены где-то еще, но ни в stdlib.h, ни в других стандартных заголовках, но в memory.h.Он все еще может существовать в вашей системе, он, безусловно, все еще существует в OS X (на сегодняшний день).

memory.h в OS X 10.11 (без заголовка лицензии):

#include <string.h>

Весь файл только #include '* string.h, чтобы сохранить обратную совместимость с Pre-StandardПрограммы на Си.

Answer 4

Помимо исторических соображений, разделение утилит для манипулирования данными, таких как string.h, и системных функций, таких как malloc в stdlib.h, имеет большой смысл, когда вы рассматриваете контексты, в которых операционная система не является заданной. Встроенные системы могут иметь или не иметь ОСРВ, и они могут иметь или не иметь стандартное доступное распределение памяти. Однако такие утилиты, как strcpy и memcpy, занимают аналогичное пространство в том смысле, что они не зависят от каких-либо внешних систем и поэтому могут запускаться в любом контексте, в котором вы можете запускать скомпилированный код. Концептуально и практически имеет смысл объединить их и отделить от более сложных системных вызовов.