Vous voyez, c'est un exemple complet, fonctionnel et compilable. N'hésitez pas à le compiler vous-même et à le tester, ça marche vraiment. Vous devez appeler le programme depuis un terminal comme celui-ci :

Maintenant, concentrons-nous sur l'appel read lui-même :

La signature de lecture est la suivante (extraite des pages de manuel Linux) :

Premièrement, l'argument fd représente le descripteur de fichier. J'ai expliqué un peu ce concept dans mon article de fourche.  Un descripteur de fichier est un int représentant un fichier ouvert, socket, pipe, FIFO, périphérique, eh bien c'est beaucoup de choses où les données peuvent être lues ou écrites, généralement de manière similaire à un flux. J'y reviendrai plus en profondeur dans un prochain article.

La fonction open est l'un des moyens de dire à Linux : je veux faire des choses avec le fichier dans ce chemin, veuillez le trouver où il se trouve et me donner accès. Il vous rendra ce descripteur de fichier int appelé et maintenant, si vous voulez faire quelque chose avec ce fichier, utilisez ce numéro. N'oubliez pas d'appeler close lorsque vous avez terminé avec le fichier, comme dans l'exemple.

Vous devez donc fournir ce numéro spécial pour lire. Ensuite, il y a l'argument buf. Vous devez ici fournir un pointeur vers le tableau où read stockera vos données. Enfin, count est le nombre d'octets qu'il lira au plus.

La valeur de retour est de type ssize_t. Type étrange, n'est-ce pas? Cela signifie "signé size_t", en gros c'est un long int. Il renvoie le nombre d'octets qu'il lit avec succès, ou -1 en cas de problème. Vous pouvez trouver la cause exacte du problème dans la variable globale errno créée par Linux, définie dans . Mais pour imprimer un message d'erreur, il est préférable d'utiliser perror car il imprime errno en votre nom.

Dans les fichiers normaux - et seul dans ce cas - read renverra moins que count uniquement si vous avez atteint la fin du fichier. Le tableau buf que vous fournissez doit être assez grand pour contenir au moins un nombre d'octets, ou votre programme peut planter ou créer un bogue de sécurité.

Maintenant, lire n'est pas seulement utile pour les fichiers normaux et si vous voulez ressentir ses super-pouvoirs - Oui je sais que ce n'est dans aucune bande dessinée de Marvel mais il a de vrais pouvoirs - vous voudrez l'utiliser avec d'autres flux tels que des tuyaux ou des sockets. Jetons un coup d'oeil là-dessus :

Fichiers spéciaux Linux et appel système de lecture

Le fait que read fonctionne avec une variété de fichiers tels que des tuyaux, des sockets, des FIFO ou des périphériques spéciaux tels qu'un disque ou un port série est ce qui le rend vraiment plus puissant. Avec quelques adaptations, vous pouvez faire des choses vraiment intéressantes. Premièrement, cela signifie que vous pouvez littéralement écrire des fonctions fonctionnant sur un fichier et l'utiliser avec un tube à la place. C'est intéressant de transmettre des données sans jamais toucher le disque, assurant les meilleures performances.

Cependant, cela déclenche également des règles spéciales. Prenons l'exemple d'une lecture d'une ligne depuis un terminal par rapport à un fichier normal. Lorsque vous appelez read sur un fichier normal, Linux n'a besoin que de quelques millisecondes pour obtenir la quantité de données que vous demandez.

Mais quand il s'agit de terminal, c'est une autre histoire : disons que vous demandez un nom d'utilisateur. L'utilisateur tape dans le terminal son nom d'utilisateur et appuie sur Entrée. Maintenant, vous suivez mes conseils ci-dessus et vous appelez read avec un gros tampon tel que 256 octets.

Si la lecture fonctionnait comme avec les fichiers, elle attendrait que l'utilisateur tape 256 caractères avant de revenir! Votre utilisateur attendrait indéfiniment, puis tuerait malheureusement votre application. Ce n'est certainement pas ce que vous voulez, et vous auriez un gros problème.

D'accord, vous pouvez lire un octet à la fois mais cette solution de contournement est terriblement inefficace, comme je vous l'ai dit plus haut. ça doit marcher mieux que ça.

Mais les développeurs Linux ont pensé lire différemment pour éviter ce problème :

• Lorsque vous lisez des fichiers normaux, il essaie autant que possible de lire le nombre d'octets et il obtiendra activement les octets du disque si cela est nécessaire.
• Pour tous les autres types de fichiers, il renverra aussitôt que il y a des données disponibles et au plus compter les octets :
  1. Pour les terminaux, c'est généralement lorsque l'utilisateur appuie sur la touche Entrée.
  2. Pour les sockets TCP, c'est dès que votre ordinateur reçoit quelque chose, peu importe le nombre d'octets qu'il reçoit.
  3. Pour FIFO ou tuyaux, c'est généralement le même montant que ce que l'autre application a écrit, mais le noyau Linux peut fournir moins à la fois si c'est plus pratique.

Vous pouvez donc appeler en toute sécurité avec votre tampon de 2 KiB sans rester enfermé pour toujours. Notez qu'il peut également être interrompu si l'application reçoit un signal. Comme la lecture de toutes ces sources peut prendre des secondes voire des heures - jusqu'à ce que l'autre partie décide d'écrire, après tout - être interrompu par des signaux permet de ne plus rester bloqué trop longtemps.

Cela présente également un inconvénient : lorsque vous souhaitez lire exactement 2 Kio avec ces fichiers spéciaux, vous devez vérifier la valeur de retour de read et appeler read plusieurs fois. read remplira rarement tout votre tampon. Si votre application utilise des signaux, vous devrez également vérifier si la lecture a échoué avec -1 car elle a été interrompue par un signal, en utilisant errno.

Laissez-moi vous montrer comment il peut être intéressant d'utiliser cette propriété spéciale de read :