Pourquoi les fonctions de mémoire telles que memset, memchr... sont dans string.h, mais pas dans stdlib.h avec d'autres fonctions de mémoire ?

Question

Je me demande, pourquoi une telle fonction comme :
-memset
-memmov
-memchr
-memcpy

Existe dans le fichier d'en-tête string.h, mais pas dans le fichier stdlib.h, où il y a d'autres fonctions de mémoire standard comme l'allocation dynamique de mémoire : malloc, calloc, realloc, free.

Peut-être serait-il préférable de les réunir dans un seul en-tête ? Qu'en pensez-vous ? Je ne comprends pas pourquoi un ensemble de fonctions mémoire est séparé des autres et existe dans l'en-tête string ( string.h ).

Answer 1

Parce qu'en fait string.h est défini comme un en-tête standard qui déclare les fonctions qui traitent les tableaux de caractères et pas seulement les chaînes de caractères. Des fonctions comme memcpy y memset prennent des arguments qui sont traités comme des pointeurs vers le premier élément d'un objet de type tableau de caractères.

(C99, 7.21.1p1) L'en-tête < string.h > déclare un type et plusieurs fonctions, et définit une macro utile pour manipuler des tableaux de type caractère et d'autres objets traités comme des tableaux de type caractère.

Answer 2

Je ne penserais pas vraiment à la string.h comme des fonctions de "mémoire". Je les considérerais plutôt comme des fonctions "tableau", puisqu'elles opèrent sur les données contenues dans les séquences de la mémoire. En revanche, malloc (et d'autres), fournissent en fait des services de mémoire tels que l'allocation, plutôt que la manipulation des données dans une région de la mémoire.

En particulier, les fonctions dans string.h ne s'occupent pas de l'allocation ou de la désallocation de la mémoire, ni d'aucune forme de gestion de la mémoire. Même une fonction comme char * strerror(int) qui semble créer une toute nouvelle chaîne de caractères, n'effectue aucune allocation, car la valeur de retour est en fait une chaîne de caractères allouée statiquement. Les autres fonctions peuvent renvoyer un pointeur vers un bloc de mémoire, mais il s'agit en fait d'un de leurs paramètres (par ex. memcpy ). Ou ils renvoient un pointeur vers le début d'une sous-chaîne ( strtok ), ou un nombre entier représentant une comparaison ( memcmp ).

D'un autre côté, stdlib.h n'est pas non plus vraiment une question de mémoire. La conception de stdlib.h est de fournir des opérations générales dont un grand nombre de programmes auront probablement besoin. Les fonctions de mémoire ne sont que des exemples de ces opérations fondamentales. Cependant, d'autres fonctions comme exit y system sont également de bons exemples, mais ne s'appliquent pas à la mémoire.

Maintenant, il y a quelques fonctions dans stdlib.h que l'OMI aurait pu placer dans string.h notamment les différentes fonctions de conversion ( mbstowcs , wcstombs , atoi , strtod etc.), et peut-être même le bsearch y qsort fonctions. Ces fonctions suivent les mêmes principes que les string.h (elles opèrent sur des tableaux, ne retournent pas les blocs de mémoire nouvellement alloués, etc).

Mais d'un point de vue pratique, même si cela avait beaucoup de sens de combiner les mem* avec les fonctions malloc , realloc , calloc y free la bibliothèque standard de C est jamais va être réorganisé de la sorte. Un tel changement casserait définitivement le code. Aussi, stdlib.h y string.h existent depuis si longtemps, et sont toutes deux des bibliothèques si utiles et fondamentales, que les modifications apportées briseraient probablement la plupart (ou du moins, une grande partie) du code C.

Answer 3

Dans le C pré-standard, ces fonctions étaient en effet définies ailleurs, mais pas dans le module stdlib.h ni dans aucun des autres en-têtes standard, mais dans memory.h . Il existe peut-être encore sur votre système, il existe certainement encore sur OS X (à ce jour).

memory.h sur OS X 10.11 (sans en-tête de licence) :

#include <string.h>

L'ensemble du fichier est seulement #include 'ing string.h afin de conserver une compatibilité descendante avec les programmes C pré-standard.

Answer 4

Outre les considérations historiques, la séparation des utilitaires de manipulation des données, comme ceux de l'application string.h et les fonctions du système comme malloc sur stdlib.h a beaucoup de sens si l'on considère les contextes où un système d'exploitation n'est pas acquis. Les systèmes embarqués peuvent ou non avoir un RTOS et ils peuvent ou non disposer d'une allocation de mémoire standard. Cependant, des utilitaires comme strcpy y memcpy occupent un espace similaire dans la mesure où ils ne dépendent d'aucun système externe et peuvent donc être exécutés dans n'importe quel contexte où vous pouvez exécuter du code compilé. D'un point de vue conceptuel et pratique, il est logique de les regrouper et de les séparer des appels système plus complexes.